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The Personal Computer Lllith 
Abstrect 



The personal work station offers significant advantages over the 
large-scale, central computing facility accessed via a termlnel. 
Among them are availability, reliability, simplicity of 
operation, end a high bandwidth to the user. Modern technology 
allows to build systems for high-level language programming with 
significant computing power for a reasonable price* 

At the tnstitut fur Xnformatik of ETH we have designed and built 
such a personal computer tailored to the language Modula-2. This 
paper is a report on this project which encompasses language 
design, development of a compiler and a single-user operating 
system, design of an architecture suitable for compiling and 
yielding a high density of code, and the development and 
construction of the hardware. 2i Lllith computers are now in use 
at ETH. 

A principal theme Is that the requirements of software 
engineering influence the design of the language, and that its 
facilities are reflected by the architecture of the computer and 
the structure of the hardware. That the hardware should be 
designed according to the programming language, Instead of vice- 
versa, is particularly relevant In view of the current trend 
towards VLSI technology. 



_ 2 - 





- 3 - 
1 . Introduction 



Software Engineering build* upon two pillars; Methods and tools. 
Thalr interrelation Is strong. In order to apply new Methods 
effectively* we need the appropriate tools, In order to build 
supporting tools* we must staster powerful Methods. Much effort 
has been spent on improving our Methods, particularly in 
programing, and Many discussions and conferences have been 
devoted to the subject of furthering the state of the art by 
applying More effective Methods. This includes a tendency 
towards tha highly MatheMatical treatMent of programming, the 
postulation of high-level languages for prograMMing large 
systems, the Method of structured prograMMing* and the 
Managerial aspects of organising the work of programmers' teaMS. 

All of these areas sre Important! they focM the part of a whole. 
But perhaps none is as inportant as the adequate training of the 
individual tea* nunber Into a habit of systematic thinking. Mo 
team can be successful without all Its Members being trained to 
regard prog reaming as a highly logical and MatheMatical 
activity. And the success of a MatheMatical treatMent rests 
largely on the usa of an adequate notation. I.e. prograMMing 
"language". The designer of algorithms Might be content with the 
adequate notation and regard it as his only tool needed. 
However, our subject at large Is not tha design of algorithms or 
programs, but the design of machines. We must regard programming 
as designing machinery, for programs turn "raw hardware" Into 
that Machinery which fulfils the specified task. 

Obviously a good notation must therefore be supported by *n 
excellent implementation* just as a good mathematical framework 
for program design must be supported by an appropriate notation. 
Moving one step further, tha notation's implementation must be 
supported by an appropriate computer system. The measure of its 
quality not only includes aspects of computing power* cost- 
effectiveness* and software support (the so-called prograMMing 
environMent) * but also a slMpllclty and perspicuity of the 
antic* system, a convenience to use the system, a high degrae of 
availability* and - on the Mora technical side - a high 
bandwidth of information transfer between coMputer and 
programmer. The latter aspects point In tha direction of a 
personal work station in contrast to the remote, tiMe-shared, 
large-seal* computing facility. 

fortunately* Modern semiconductor technology has Made it 
possible to iMpleMent a Modern prograMMing language with 
excellent support facilities on relatively small computers that 
are very inexpensive compared to conventional large computing 
installations. The fact that the machaniSM* for sharing a 
coMputer - and In particular that for protecting the users from 
the Mistakes of others - can be discarded* reduces a system's 
complexity drastically* and thereby Improves both Its 
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re liability and perspicuity. The possibility to Implement 
aodern, high-level languages on relatively Smalt non-shared 
computers was perhaps th* tost significant "discovery* during 
the last five years, h personal computer, prog recusable in such a 
language, constitutes, tn my opinion, a necessary tool Cor the 
creative software engineer of the future. 

2. Project history and overview 

The decision to design and build a personal computer »m 
motivated above was made in the fall of 1977, after the author 

an Alto 
pal parts 



had learned to appreciate the advantages of working with 
computer (H* ^ e project Included the following princlp 
{21: 



- design of the programming language Hodula-2. 

- Implementation of a multipass compiler suitable for relatively 
small computers. 

- development of a basic, single-user operating system, 
including a file system and a linking loader. 

- design and implementation of a modern, flexible text editor 
taking full advantage of the computer's capabilities. 

- implementation of a set of basic utility programs for file 
directory Inspection, copying, renaming, deleting, and listing 
files. 

- programming »n^ implementing an appropriate set of library 
modules for file handling, access to peripheral devices - in 
particular the display - and storage management. 

- designing a suitable machine architecture as ideal interface 
between compiler and hardware, and programming this 
architecture tn microcode. 

- design of the hardware capable of efficiently interpreting the 
microcode and supporting the desirable peripheral devices. 

- building two prototypes of the designed hardware, and 
modifying them according to Insight gained from the 
concurrent development of hard- and software. 

- building a series of 2i computers, debugging and testing them. 

- writing documentation and user manuals. 

The language Hodula-2 - the notation in which this system 
presents itself to the software engineer - was designed as a 
general system programming language [3|. The guiding principle 
was that this language would be the only language available on 
the computer . Especially, no assembler would be available, and 
hence, the language should be suitable for both high-level 
programming in a machine- independent manner and low-level 
programming of machine-particular aspects, such as device 
handling and storage allocation, in fact, the entire operating 
system, the compiler, the utility programs, and the library 
modules are programmed exclusively in Hodula-2. 
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Tli* compiler is subdivided into four parts. Each part processes 
the output of its predecessor in sequential fashion and is 
therefore called a pass. The first pass performs lexical and 
syntactic analysis, and it collects Identifiers* allocating them 
in a table. The second pass processes declarations, generating 
the so-called symbol tables that are accessed in the third pass 
to perform the type consistency checking in expressions and 
statements. The fourth pass generates code. Its output is called 
K-code. 

The operating ays tea is conceived according to the concept of an 
"open" system HI. It is divided into three principal parts* 
namely the Unking loader, the file system, and routines for 
keyboard Input and text output on the display. The file system 
maps abstract (Ilea (sequences of words or characters! onto disk 
pages JktUt provides the necessary basic routines for creating, 
naming, writing, reading, positioning, and deleting files. Both, 
loader and file system present themselves to the Modula-2 
programmer as nodules (packages) whose routines can be imported 
into any program. Whenever a program terminates, the basic 
operating system activates the command interpreter which 
requests the file name of the next program to be loaded and 
Ini tiated . 

The computer as *seen by the compiler" is implemented tt» a 
microprogrammed interpreter of the H-code, The tf-code is 
designed with the principal goals of obtaining a high density of 
code and of making the process of its generation relatively 
systematic and straight-forward. Although space is definitely 
the scarcer resource than time, a high density of code is 
desirable not only In the Interest of saving memory space, but 
also for reducing the frequency of instruction fetches. A 
comparison between two different, but strongly related compilers 
revealed that H-code is shorter than code for the PDP-11 by a 
factor of almost a. This surprising figure Is clear evidence of 
the inappropriate structure of "conventional" computer 
instruction sets. Including those of most modern microprocessors 
that were still designed with the human assembly language coder 
in mind. 

The actual hardware consists of a central processing unit based 
on en Am29S1 bit-slice unit, a multi-port memory with 128K words 
of 16 bits, a micro-code memory of 2K Instructions implemented 
with PROHs, a controller each for the display, the disk, and a 
local network, and Interfaces for the keyboard, a cursor 
tracking device called the mouse, and a V~24 (RS-232) serial 
tine interface. The central processor operates at a basic clock 
cycle of IS! ns, the time required to interpret a micro- 
instruction. The most frequently occur ing H-code instructions 
correspond to about 5 micro-instructions on the average. 

The display is based on the raster scan technique using 594 
lines of 768 dots each. Each of the 456*192 dots is represented 
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In main Memory by one bit. if the entire screen is Cully used* 
Its bitmap occupies 28*512 words, i.e. 22% of memory, the 
representation of each dot (picture element) in program 
accessible main memory makes the display equally suitable for 
text, technical diagrams, and graphics in general. In the case 
of text, each character is generated by copying the character's 
bitmap into the appropriate place of the entire screen's bitmap. 
This is done by software, supported by appropriate microcoded 
routines, corresponding to special M-code instructions. This 
solution, in contrast to hardware character generators, offers 
the possibility to vary the characters* size, thickness 
(boldface) , inclination (italics) and even style* In short, 
different fonts can be displayed. This feature, which is 
particularly attractive for text processing, requires a 
substantial amount of computing power to be available in short 
bursts. The writing of a full screen, 1 ,e. conversion of 
characters from ASCII code to correctly positioned bitmaps, 
takes about 1/1 second. Using a small font, a full screen may 
display up to 10*000 characters. 

The disk used in this personal computer is a Honeywell-mull 
D-120 cartridge disk with a capacity of li MBytes and a 
potential transfer rate of 720 kB/s, which results in an actual 
rate of 60 kB/s for reading or writing of sequential files. Disk 
sectors, each containing 256 Bytes, are allocated in multiples 
of on the same track. Allocation is entirely dynamic, and 
hence no storage contraction processes are needed to retrieve 
"holes*. The use of exchangeable cartridge disks in contrast to 
sealed (Winchester) disks has been considered »m essential in 
order that a work station may be used by different people at 
different times without reliance on the existence of a network 
and a central file store. 

The mouse is a device that transmits signals to the computer 
which represent the mouse's movements on the table. These 
movements are translated (again by software) Into a cursor 
displayed on. the screen. The accuracy of position is as high as 
the resolution of the screen, because the feedback from cursor 
to mouse travels via the user's eye and hand. The mouse also 
contains three pushbuttons (keys) which are convenient for 
giving commands while positioning the mouse. 

The various principal parts of the projects were undertaken more 
or less concurrently. The team consisted of t (part time) people 
in the average (not counting the production of 21 machines}, and 
was smell enough to require neither management staff nor 
methods. The hardware was designed and built by three engineers 
( including the author) , two computer scientists built the 
compiler, one the operating system, one Implemented the 
microcode and nost of the editor. The software effort was based 
on the use of a PDP- 11/40 computer (with a 28K store) and was 
initiated with the development of a compiler for Modula-2 
generating code for the PDP-1 1 Itself. This "preliminary" 
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compl ler development const i tuted a sign! E leant part of the 
entire software effort, and resulted in a valuable software tool 
that had recently been released for distribution. It also made 
the development of the Llllth software quite independent from 
the progress of the hardware, Both the Modula-2 compiler for M- 
code, the operating system, and even the highly display-oriented 
editor were developed on the POP-} 1 » and the subsequent 
transport to the til 1th computer proved to be quite 
unproblematlc due to programming In - Modula-2, In fact, the 
untested compiler was transported and debugged (at least to an 
acceptable degree) In a few days only. 

Whereas the software development could profit from our previous 
experience in designing compilers and programming in general, 
such was not the case in the hardware sector, as our institute 
had net ther hardware expertise nor facilities. To gain 
experience and develop such facilities was, however, a prime 
challenge, and this project offered a welcome opportunity. 

Prom the start it was planned to base the Llllth computer on the 
29il bit-slice processor, because one-chip processors available 
in 1977 did not offer the computing speed required for the 
efficient handling of the planned bitmap operations. This 
dec i si on proved to be a good one , After 15 mon ths o £ 
development, a first prototype was operational (without disk), 
proved to be too unreliable for extensive use, but confirmed the 
sensibility of the overall design. An additional year was needed 
to produce two identical prototypes which served to test the 
software that had been developed in the meantime. In the spring 
of 19S0, a team was formed at the Department of Electrical 
Engineering of Brigham Young University in Provo, Utah, to build 
a series of 20 Llllth computers. This goal was achieved within 8 
months by three graduating engineers and with the aid of student 
employees during the summer months. The cost per unit, not 
counting the development of the prototypes nor of organizing the 
production effort , but Including labor and parts, In particular 
the 1SMB disk, was about SFr 28*980, 

In the meantime, a few important application programs were 
written at ETH, including a text editor, an editor for drawing 
circuit diagrams, and a window handler module. Some sample 
pictures illustrating their use are shown In fig 1. They are 
printed with the same resolution as seen on the screen. 

3. Modules and interfaces In Modula-2 



Perhaps the most important criterion of a language for 
programming large systems Is how well it supports program 
modular ization. The earliest facll ities introduced for effective 
program decomposition was the concept of locality, 1 .e. the 
restriction of the validity of names (Identifiers) to well™ 
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delineated parts at the program, such as * block or * procedure. 
This concept was Introduced by Algol 6f end adopted in Algol 6«, 
Pt/I, and Pascal, among others. The range of validity is called 
a name's scope. Scopes can be nested, end the rule Is thet names 
valid in the scope's environment are also valid inside it, 
whereas names declared within the scope are invisible outside* 
this rule immediately suggests a connection between the range of 
visibility (scope) of a name within the program test, and the 
time of existence of the object associated with the namet as 
soon as control enters the scope (procedure, bloc It 1, the object 
must be created (e.g. storage must be allocated to a variable), 
and as soon as it leaves the scope, the object can be deleted, 
for it will no longer be visible. In spite of the tremendous 
value of this locality concept, there are two reasons why it is 
inadequate for large programs. 

- there is a need to hide objects, i.e. to retain them while 
they are invisible, this calls for a separation of visibility 
and existence; visibltty as a property of names, existence as 
a property of objects. 

- there is a need for closer control of visibility, i.e. for 
selection of particular names to be visible or Invisible, in 
contrast to the 'inheritance" of the total environment into a 
local scope. 

In Modula-2, we have therefore added the structure of a module 
to the structure of the procedure. Both structures appear 
syntactically as almost identical, but are governed by different 
rules about visibility of local names and existence of the 
associated objects* 

PI. An object declared local to a procedure exists only as long 
as the procedure remains activated. 

HI, An object local to a module exists as long as the enclosing 
procedure remains activated. 

P2. A name local to a procedure is Invisible outside the text of 
that procedure, one visible in the environment is also 
visible inside the procedure. 

M2. A name local to a module is visible inside the module, and 
outside'" too, if It appears in the so-called export list in 
the module heading. A name visible in a module's environment 
is visible inside that module only If it appears in its so- 
called import list. 

from these rules, we can draw the following conclusion: A module 
itself has no "existence", since its local objects inherit their 
lifetime from the module's environment (procedure). Hence, the 
module is a purely syntactic structure acting like a wall 
enclosing its local objects and controlling their visibility by 
means of export and import lists. Modules therefore need not be 
Instantiated; there are no instances of a module. The module Is 
merely a textual unit. 
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A typical example of a nodule is the following: 

MODULE n; 

IMPORT u,v| 
EXPORT p,qj 

Von X t * * * J 

PROCEDURE p(...) j 

BEGIN ... x ... END p; 
PROCEDURE q|...)| 

BEGIN ... x ... END qj 
BEGIN ... U ... X ... 
END • 

This nodule owns three local objects: variable x and procedures 
p and q operating on x. It exports p and q and hides x by not 
exporting it. The body of the module serves to initialize x; it 
is activated when the environment of m is activated (created) . 
This example is typical, because It shows how an object x can be 
hidden and how access from outside is restricted to occur via 
specific procedures. This wakes It possible to guarantee the 
existence of Invariant conditions on x, independent of possible 
errors In the environment accessing x via p and q. Such is the 
very purpose of Modularization. 

The typical purpose of a nodule is indeed to hide a set of 
interrelated objects, and the nodule is often identified by 
these objects, e.g. a table handler hiding the table, a scanner 
hiding the input stream, a terninal driver hiding the interface, 
or a disk system hiding the disk's structure and allocation 
strategy. 

The nodule concept as described above had been introduced with 
the language Hodula (51. Modula-2 extends this concept in two 
important ways, namely by 

- qualified export node, and 

- subdivision of a nodule into two textual parts, the so-called 
definition and implementation parts. 

Qual i fled export serves to avoid clashes between identical 
identifiers exported from different nodules into the sane 
enclosing scope. If an Identifier x is exported In qualified 
node fron a nodule n, then the object associated with x needs to 
be denoted as n.x. The qualified mode is therefore appropriate, 
if the writer of m does not know the environment of m. This is 
not the usual case for nested modules; individual members of a 
programming team more typically design modules that lie on the 
sane level , namely the outermost, or global level ( that nay be 
considered as being enclosed in a universal and empty scope). It 
Is this case that Is particularly important in the design of 
large systems, where a better separation of the specification of 
inport and export lists from the description of the actual 
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objects is desirable. 

Consequently, we divide a global module Into two parts. The 
first is called a definition module; It contains the export list 
and specifications of the exported objects as far as relevant 
for the user (client) of this Module to verify the adherence to 
language rules (in particular type consistency}, A definition 
nodule also specifies the types of its exported variables and 
the parameter lists of its exported procedures. The second part 
Is called the implementation module. It contains (usually! 
Import lists and all the details that need not concern the 
client, such as the bodies of procedures. The notion of 
textually separate definition and implementation parts was 
pioneered by the language Hesa (6| and is here smoothly 
integrated with the module concept of Module. 

Example: 

DeriHITION MODULE Bf 

EXPORT QUALIFIED p,q; 

PROCEDURE p< . ..); 

PROCEDURE <j( .. .) t 
END B. 

IMPLEMENTATION MODULE &; 
PROM A IMPORT u,V; 

PROCEDURE pf ...)} 

BEGIN ... x ... u ... END pj 
PROCEDURE q(...); 

BEGIN ... v ... X ... END q; 
BEGIN ... x ... 
END B. 



4. Coroutines and processes 

With the design of the Lilith computer we did not follow the 
fashionable trend to design a system consisting of several co- 
operating concurrent processors, thereby avoiding one certain 
source of difficulties* namely their synchronisation. The 
consequence for the language Modula-2 was that the concept of 
concurrent processes played a minor role only, whereas tn 
Modula-1 it had been the major theme. The primary idea had been 
to distinguish the logical process from the physical processor, 
allowing implementations ' to choose their own mechanisms for 
allocating processors to processes. Logical processes are served 
by time-sharing the processors, which may well have different 
characteristics and capabilities. The processes are Implemented 
as coroutines, and transfers of control between them are implied 
in statements that send signals or wait to receive signals, 
where the signal Is *n abstract notion represented as a data 
type. Each processor executes a sequence of coroutine segments, 
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and the processor scheduling can well be hidden behind the 
primitive operations on signals. The principal difference 
between processes (as in Modula-l) and coroutines (as In Modula- 
2) Is that the latter are explicitly identified whenever a 
transfer occurs, whereas processes are not, since transfers are 
implied by sending a named signal to some process which regains 
anonymous* 

It Is well In accordance with the premise of Modula-2 - namely 
to make primitives directly available to the programmer - to 
include coroutines instead of processes, because the latter are 
Implemented by the former. As a consequence, Modula-2 
implementations need no "run-time system" and no fixed, built-in 
schedul Ing algorithm. There exists no data type Signal , but 
instead transfer of control from a coroutine P to a coroutine Q 
Is specified explicitly by the statement TRANSFER(P.Q) . Here P 
and are variables of the prlnittve type PROCESS, whose actual 
values are pointers to the coroutines' workspace and state 
descriptors. 

Furthermore, experience with Modula-1 showed the advisability of 
separating interrupt-driven from "regular" processes, because an 
interrupt signals a transfer of service among processors within 
the same process. A programmer may adopt this advice by 
supplying his own scheduling program. Hodula-2 provides the 
appropriate mechanism for encapsulating such a user-defined 
scheduler lit the form of its module structure* Naturally, such 
algorithms may also be provided In the form of library modules. 

As an example we list a scheduler reflecting the simple round- 
robin algorithm. The module exports the data type Signal and the 
operators StartProcess, Send, and Halt, which correspond to the 
language facilities of Modula-1. The example excludes, however, 
the treatment of lnterrupt-drlven processes. (Note that the type 
Signal is exported In opaque mode such that its structures is 
Invisible to the importer.) Soth Send and Walt imply a coroutine 
transfer. The primitive operation TRANSFER is, like the data 
type PROCESS, imported from the module SYSTEM, which typically 
contains low- level facll ities. High-level programs should 
preferrably rely on the process concept as presented by such a 
Process Scheduler module, rather than on named coroutines and 
explicit transfer of control. 



DEFINITION MODULE ProcessSceduler j 
FROM SYSTEM IHPORT ADDRESS; 
EXPORT QUALIFIED Signal, StartProcess, Send, Walt] 

TYPE Signal; 

PROCEDURE StartProcessf P: PROC; A: ADDRESS; nz CARDINAL) 
PROCEDURE Send(VAR s: Signal); 
PROCEDURE WaltlVAR s: Signal); 
END ProcessScheduier . 
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IMPLEMENTATION MODULE ProcessScneduleri 

FROM SYSTEM IMPORT PROCESS, ADDRESS, MEWPROCESS, TRANSFER} 

TYPE Signal - POINTER TO ProcesaDeecriptor | 
FrocessDescriptor * 

RECORD ready; BOOLEAN} 
pr t PROCESS j 

nextt Signalf (* ring *) 
queue i Signal i |* waiting queue *) 
END f 

VAR cp; Signal} 4* current process *) 

PROCEDURE StartProcesstPt PROC| At ADDRESS} ni CARDINAL}} 

(* start P with workspace A of length n *) 

VAR tt Signalj 
BEGIN t t- cpj NEM(cp)} 

WITH cp* DO 

next t" t**.ne«tf ready i* TRUE} 
queue i- NIL} t .next :» cp 

END } 

NEKPROCESSfF, A, n, cp".pr)| TRAMSFERft" .pr , cp' .pr} 
ENO Startprocese} 

PROCEDURE Send I VAR it Signal)} 

(* resume first process watting for s *} 
VAR tt Signal} 
BEGIN 

IP s | NIL THEN 
t s» cpj cp i» Sj 
WITH cp* DO 

S ;- queue} ready t» TRUE} queue I* NIL 
EMD } 

TRANSFER (t*.pr # cp'.pr) 
END 
END Send} 

PROCEDURE Wait (VAR s: Signal)} 

VAR tt, tl: Signal} 
BEGIN (* insert current process in queue s *) 
IP 8 - NIL THEN s :- cp 
ELSE tl ;« t( 

LOOP t) t* ti". queue} 
IF tl - NIL THEN 

tB". queue t- cp} SUIT 
END } 
tfl t- tl 
END 
END } 

cp". ready i- FALSE} cp* .queue i* MIL} 
tS i- cp} (*now Hnd nest ready process*) 
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Repeat cp i» op*. next; 

If cp - fci THEN HALT ('deadlock*) END 
UNTIL cp*. ready | 
TRANSFER (tf.pr, Cp'.pr) 
END Halt) 

BEGIN NEW(cp); 

WITH cp m DO 

next :- cp; ready :- TRUE; queue i* NIL 

END 
END ProcessScheduler. 

Interrupts are transfers of control that occur at unpredictable 
moments. We can regard an interrupt as equivalent to a statement 

TRANSFER {interrupted, interrupting) 

that Is effectively Inserted in the program wherever control 
happens to be at the moment when the external interrupt request 
Is applied. The variable "interrupting" denotes the process that 
is destined to service the request , whereas the variable 
"interrupted* will be assigned the interrupted coroutine. The 
typical interrupt handler is a device driver coroutine of the 
following patternj P and Q are variables of the primitive type 
PROCESS. 

PROCEDURE driver; 
BEGIN initialization; 

LOOP , . . 

start device; TRANSFER (Q, , P) ; ... 

END 
END driver 

The driver process Is created by the primitive statement 

NEWPROCESSfdrlver ,wsp,n ,Q) 

which allocates the procedure "driver" and the workspace wsp of 
size n to this coroutine, now identified by Q. It is 
subsequently activated by the statement 

TRANSFERS, Q) 

which assigns the starting coroutine (e.g. the main program) to 
P. After Initiation of a device operation the statement 
TRANSFER (Q, P| , which symbolically stands for that part of the 
process which Is executed by the device (i.e. another processor) 
actually returns control to P and assigns (the current state at) 
the driver coroutine back to Q. Termination of the device 
operation causes an interrupt signal which (If enabled) 
corresponds, as explained above, to an unwritten TRANSFER(P,Q) . 
This signal again switches control back from the Interupted to 
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the driver (interrupting) routine. 

Each Interrupt signal - the Ulith computer offers 8 of them - 
Is associated with its own variables P and ** fixed locations. 
In order that further interrupts remain disabled while the 
processor executes the interrupt routine, drivers are typically 
declared inside a module with specified "priority* that causes 
interrupt Inhibition up to that specified "priority" level 



elegant conceptual unification of coroutine transfers 
upt handling was made possible by an approprlel 
ied computer architecture and instruction set. 



S. The operating system 

The most noticeable aspect of the Lllith operating system Hedos 
is its orientation towards a single user. It is devoid of any 
protection mechanism against malicious programs that could 
hamper another user's program* Since Medos is programmed in 
Module, it benefits from the safety provided by Module's type 
consistency and various run-time checks. Its safety features are 
"defensive*, but certainly not invulnerable, considering the 
Module's facll it las for low-level programming offered to the 
brave programmer. In this regard* Hedos follows the strategy of 
Pilot (»). In a first, superficial look It can be regarded as a 
collection of modules that are imported by the current program 
(and its' imported modules). Since a number of low-level modules 
(such as the file system) are used by virtually every program, 
they form a resident section. This set of modules consists of 
three main parts; 

"Program* - storage allocation, program loader 
"Terminal" - drivers for keyboard and display 
"FileSystem* - disk driver and file administration 

The module Program exports the procedures 

Call (name, she redMeap, status) 

AllocateHeap(size) 

DeallocateHeap(sixe) 

of which the first effectively represents the loader. The module 
administers the entire store as a stack and loads called 
program's sequentially. The remainder of the store Is treated as 
data store. In this part, the data stack grows from one %ni and 
the heap from the other* The heap is used for variables that are 
allocated dynamically by calls of AllocateHeap and 
DeallbcateUeap, which merely move the pointer that denotes the 
separation between data stack and heap. More sophisticated 
allocators can be programmed which, however, will also refer to 
these basic procedures. 
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If a program P call* the loader* the code and data segments of 
the loaded Module Q (and of the modules Imported by Q and not 
already present} are stacked on top of those of p. The set of 
segments thus loaded fores a new "level", one higher than that 
of P. The loader operates as a coroutine, and each new level of 
prog r m Is represented as a coroutine too. This slight Misuse of 
the coroutine facility is Justified by the convenience in which 
new sections of data and program (a level} can be administered* 
if described as a coroutine. Pig. 2 shows the storage layout and 
the implied transfers of control when a prog re* is loaded fro* a 
caller at level 1* 

The set of resident Modules tot ma level f. Its stain program is 
called the Sequential Executive Kernel. It Invokes the loader 
which loads the command interpreter* This Is merely a program 
that outputs a prompt character, reads a file name, and 
transmits the file identity to the kernel, which loads this file 
after the command interpreter has terminated and control is 
returned to level f. Loading of the main program usually 
requires the loading of further modules that are specified in 
Import lists. Linking or binding of modules is simplified by the 
architecture of the Lilith computer such that It la performed 
directly upon program loading. Fig. 3 shows a typical sequence 
of programs, and how they occupy the store. 

Since a program is loaded only after removal of the command 
interpreter, and because the command interpreter typically has 
ample time to process the slow input from the keyboard, it can 
be designed with additional sophistication. ,It can search the 
file table for program files whose names match with the input so 
far received and extend it as far as It Is unambiguous. For 
example, if file names A6CD and ASCE are present, and no others 
starting with A, it may display both names after receiving "A?" 
and then allow continuation after receiving either D or C. This 
is a small but typical example of providing a convenient user 
interface without additional burden on the user f s program. 

The entire mechanism for loading and allocating is programmed 
exclusively tn *odula-2t this includes the subtle point of 
changing our view of a program as data before to code after its 
loading. In Modula-2, this is possible without resorting to 
tricky programming and without the escape to small sections of 
assembly code. 

the second principal part of the set of resident modules handles 
input from the keyboard and output to the display. This module 
is called Terminal. The input stream fetched by the procedure 
H«*& (contained in Terminal) flows through a switch that allows 
reading from a file Instead of the keyboard. Because the command 
interpreter also calls Read, that file can even be a command 
file. The output stream, which is fed by calling the procedure 
Write, ts fed to the low-level module TextScreen that simulates 
sequential writing and generates the bit pattern for each 
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character according to a default font. 

Th« module FileSystem constitutes the third major part of the 
resident system, riles are used for three main purposes t 

- long-term storage of data on permanent, named files, 

- communication among programs, 

- secondary storage of data on temporary* unnamed flies* 

We distinguish between the naming and abstract definition of 
files as extendable arrays of elements (FileSystem) and the 
physical implementation of files on the disk (DlskSystsm) . The 

frog rammer refers to files through the nodule FileSystem which 
n turn calls procedures of the module DlskSystsm hiding the 
details of their physical representation. 

FileSystem exports the type File and operations on this type for 
opening (creating), naming, reading, writing, modifying, 
positioning, and closing files. Normally Cties are regarded as 
streams of either words or characters; writing occurs at the end 
of the stream only, and if writing is requested at some position 
other than, the end, the file's tail Is lost and deallocated. 
Although It is also possible to modify files. I.e. overwrite 
then, the abstraction of the stream is the preferred view of 
files. 

The module DlskSystsm implements Files on th* Honeywell-Bull 
D-129 disk. It is designed according to the following main 
requirements: 

- fast access, in particular if strictly sequential, 

- robustness against hard- and software failures, 

- accommodation of a large number of (mostly short) files, 

- economical use of storage space. 

The following scheme was chosen as a compromise between the 
various design objectives! Space Is allocated In blocks of 2MB 
bytes. This results In a memory resident allocation table of 392 
words (one per cylinder), each bit indicating whether or not its 
corresponding block Is allocated to some file. Each block 
corresponds to 8 disk sectors, equally spaced on the same 
cylinder. A separate file, allocated at a fixed place, is called 
FlleOirectory and consists of file descriptors, Every file Is 
Identified by the index of its (first) descriptor (» file 
number), and each descriptor contains a table of addresses of 
the blocks which constitute the file. Additionally, the 
descriptor specifies various properties of the file, such mm Its 
length, creation date, last modification date, whether It Is 
pe rmanent , pr otec ted , e tc . Upon star tup , the system reads the 
entire FlleOirectory and computes the allocation table. 

Unnamed files are released either by closing them or when the 
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system Is started. They are used as temporary Hies during 
execution of a program. For long term storage of data, a file 
has to be named, to administer permanent flies* the nodule 
Disk System maintains another ills (also placed in a fixed 
location) called the Name Directory. Each entry consists of a 
file name and the number of the associated file. The procedure 
Lookup(f *name* create) Is used to search the name in the Name 
Directory and connects the file (If found) with the file 
variable f , The parameter "create" allows to ask for the 
creation and naming of a new file, 1 f the specified name was not 
found (see Fig. 4} . 

h fourth, but effecttvly hidden part of the resident system is 
called the Monitor. It contains two auxiliary processes that are 
used to monitor the third* namely the main process of the user. 
The auxiliary processes are called Clock and Trap (Fig. 5). 
Clock is invoked 50 times per second. It updates a variable 
called time, Monitors the keyboard bf polling, and buffers 
keyboard Input, allowing for typing ahead. 

Trap Is invoked by various instructions detecting abnormal 
conditions* such as stack overflow* arithmetic overflow, index 
out of range, access to picture elements outside the specified 
bitmap, the standard procedure HALT, etc. The Trap process then 
may store the state of the main process {essentially a dump} on 
the disk for possible later inspection by a debugger program* 
and restarts the main process at the kernel level. 

Typing the control character <ctrl>C Is detected by Clock and 
causes an abortion of the main process In the same manner as a 
trap. Evidently, abnormal situations are here handled by 
coroutine transfers instead of an additional exception facility 
provided in the programming language. The auxiliary coroutine 
then regards the aborted coroutine as data { instead of as a 
program) and Is thereby able to reset it to a state where 
continuation is sensible. 

Fig. 6 shows the principal modules of Medos with arrows denoting 
calls of procedures. Usually* these arrows are identical to 
those denoting the import/export dependences among modules, 
exceptions to this rule occur through the use of procedure 
variables. 



6. Separate compilation of Modules 

For reasons of convenience and economy , large system programs 
need to be compiled in parts. It Is only natural that these 
parts be the ones that from a logical point of view were 
designed as relatively independent uni ts. The module is the 
obvious choice for the unit of compilation. Definition and 
implementation modules are therefore called compilation units. 
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The idea of compilation In parts Is as old as fort ran and oven 
assembler code. In high-level languages with data types the 
problem of partial compilation is of considerable complexity! we 
wish that type consistence checking is fully maintained across 
module boundaries. In fact, experience has shown that this is 
when it is most needed to avoid catastrophic errors. In order to 
recognize inconsistencies such as type mismatches, incorrect 
number or order of parameters* etc., as early as possible* they 
must be detectable by the compiler, the compiler therefore must 
have access to information about all imported objects. This is 
accomplished as follows f ? 1 « 

Assume that a module B depends on, i.e. imports objects from a 
module A. Therefore, module A has to be compiled first. During 
Its compilation, th compiler generates, apart from a code file 
for A, a symbol file. Compilation of ft subsequently accesses 
that symbol file. More accurately, program S can - according to 
the rules of the language - refer to information of A*s 
definition part only. Thus, the symbol file is an extract only 
of the information available during compilation of A. Since only 
definition modules are capable of exporting, the symbol file is 
the result of compiling the definition module A, while code Is 
the result of compiling implementation tor program) modules 
only. 

This scheme - in particular the separation of definition and 
implementation parts - has important consequences for the manner 
In which systems are developed. A definition module constitutes 
the interface between its implementation part and Its clients. 
Effectively the scheme forces the programmer to define 
interfaces first, for, whenever a definition module is {changed 
and) recompiled, all its Importers {clients) have to be 
recompiled too. However, it is possible to change and recompile 
implementation modules without that far-reaching and costly 
consequence . 

It should be noted that the consequences of this chronological 
ordering of compilations are less severe than might be 
anticipated due to the fact that the Importers are usually 
implementation modules. Hence a change in a low-level module * a 
module that resides low in the hierarchical chain of 
dependencies - need not produce a chain reaction of 
recompilation up to all ultimate clients. The appropriate 
decomposition of a planned system into modules Is nevertheless a 
most important aspect, of competent programming. Often the 
decomposition has to be decided at an early stage when Insight 
Into many aspects of a system are still hazy. Its success 
therefore largely depends on the engineer's previous experience 
with similar tasks. 

Learning how to deal effectively with a new facility offered by 
a programming language Is a long-term process. Th* module 
facility forces the programmer team to make those decisions 
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first that must be made first {8). One lesson learned so far is 
that a nodule typically centers around a data structure, and 
that It is this data structure rather than .the exported 
operations that characterize It. 

7. The architecture of the Liltth computer 

One of the challenges In designing a computer lies In finding a 
structure an6 an Instruction set which yield a high density of 
code and a relatively simple algorithm for code generation, h 
premise of this project was that the computer had to be designed 
according to the language in which It was to be programmed. This 
resulted In a quite unconventional architecture. Ho attempt was 
made to make the Instruction set suitable for "hand coding"; In 
fact* programming In machine code would be quite cumbersone, 
even If an assembler were available. 

The Ltllth computer la based on a stack architecture. Stack 
computers are by no means novel as such. Their history dates 
back to the early 60s with the English Electric KDF9 and the 
Burroughs BSiftt as pioneers. The Ltllth architecture adopts the 
stack principle without compromise, and its instruction set is 
chosen to obtain a high density of code requiring only straight- 
forward algorithms for instruction selection. The code Is a byte 
stream. Each Instruction consists of one or several bytes. The 
high density ts achieved not only by implicit addressing of 
Intermediate results tn expressions, but mainly by the provision 
of different address lengths and suitable addressing modes, tn 
order to explain these modes, we need to inspect the overall 
storage organization at run- time. In contrast to earlier stack 
computers, not only procedures play an important role, but also 
modules. The underlying premise Is that objects local to the 
location of the present computation are accessed most fequently 
• and therefore require fast access by short Instructions - 
whereas access to remote objects is relatively rare »nd requires 
less efficiency. fast access is obtained by retaining 
"intermediate results* of address computations in .fast registers 
(base address), in the expectation that they will be reused 
frequently, and that thereby their recomputatlon can be avoided. 
Several base address registers are used in the Liltth computer. 

The origin of all address computations is a table with base 
addresses of all currently loaded data frames (see Fig. 7). k 
data frame is a contiguous area of store allocated to the 
(static) variables of a given module. By "module" we refer here 
and subsequently to compilation units; this excludes inner 
(nested) modules. Each loaded module has a number which is used 
as index to that frame table. The table resides at a fixed 
location and has a fixed length. The entry belonging to the 
module of which code is executed currently, is retained in the 
base address register C. It Is the base address of "Global 
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variables" in the sense of Algol or Pascal. Q has to be reloaded 
whenever control transfers iron one nodule to another. Data 
frames are static In the same sense that they are "permanent" 
Cor the duration of a program execution, with the (rare) 
exception of overlays performed by calls of the loader. 

Data local to procedures are allocated In a stack which grows 
when a procedure is called and shrinks when it Is terminated. 
Each coroutine (process) is allocated tn area of the store, 
called a stack frame, when It is started, and which serves as 
the coroutine's workspace. The base address of the stack frame 
belonging to the coroutine currently under execution is stored 
in the register P, that of the last location allocated in this 
stack frame In register S, and the tind of the workspace Is 
designated by register U. P Is used when a transfer from one 
coroutine to another coroutine occurs, S when a procedure is 
called or terminated. Each stack frame contains the hierarchy of 
data segments representing the variables local to the activated 
procedures. They are linked by the so-called dynamic chain of 
procedure activations. The base address of the last segment 
created is retained in register L (for Local data). 

Local data are semi-dynamic in the sense that they are allocated 
for the duration of a procedure activation only. However, their 
addresses are determined t>y the compiler »& offsets relative to 
the base address of their owner. Truly dynamic data are those 
allocated by explicitly programmed statements in an area of the 
store called heap, This storage area is managed by a utility 
module called Storage} these variables are accessed via pointer 
values. As in Pascal, pointers are bound to a given type, 
providing additional security In pointer handling. 



Each loaded module owns a data frame and also a code frame, a 
contiguous area of store containing the code of all Its 
procedures. The base address of the code frame of the currently 
executing module is retained In register P. Its value is used 
when calling a procedure, which Is Identified by a number used 
as index to a table containing the starting addresses of all 
procedures in a given module. This table resides in the header 
of the code frame. Using such an index Instead of absolute 
addresses contributes to higher code density, particularly since 
procedure calls are very frequent instructions. The value of 
register f is changed whenever control transfers between 
modules. Jump addresses are relative to the F-register value. 

6. The Lllith instruction set 



Instructions consist of one or several bytes. They can be 
divided into four basic categories! Load and store Instructions, 
operators, control Instructions, and miscellaneous Instructions! 
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The load and store instructions transfer data between memory 
(stack or heap) and the top of the stack, where they are 
accessed by operators. The top of the stack, where data are 
loaded as Intermediate results (anonymous variables) is also 
called the expression stack, toad or store instructions require 
a single address only bacause the stack address is implicit; 
they are further subdivided according to the following criteria: 

- data size: the transferred data are a word (16 bits), a double 
word, or a byte (halfword). 

- addressing mode: local, global, external* stack, Indexed, and 
immediate mode (the latter for load instructions only). 

- address length: i, 8, or 16 bit address (see Pig. 8)* 

The presence of different address lengths suggests that 
variables with frequent access be allocated with small offsets. 
Our present compiler does not perform any such optimization. The 
gain to be made does not appear to be overwhelming. The set of 
directly accessed (statically declared) variables is usually 
quite small , because structured variables are addressed 
indirectly. 

The various addressing modes are defined as follows (m and n 
denote Instruction parameters, and a the resulting address): 

- Local mode: a * t>n, used for variables local to procedures. 

- Global mode; a * G+n» used for global variables In the current 
module. 

- Stack model a * s+n, where s Is the value on top of the stack] 
mode used for indirect addressing and access via pointers. 

- External mode: a » T(»| +n, T is the table of data frame 
addresses, m a module number; mode used for external variables 
imported from other modules. 

~ Indexed mode: a * si + k*s2, si is the array's base address, 
s2 the computed Index (si, s2 on stack), and k is a multiplier 
depending on the size of the accessed data type. 

- Immediate mode: a * n* The loaded value Is the parameter 
itself; mode used to generate constants. 

The above explanations are given in this detail In order to show 
that the constructs defined in the programming language are 
strongly reflected by, i.e. have directly Influenced, the design 
of the tllith architecture. The beneficial consequence is not 
only ease of compilation, but simplicity of the linking loader. 
Whereas our Hodula-2 system for the PDP-11 computer for good 
reasons requires a linker, such is not necessary for the Lllith 
inplementatlon. A linker collects the code files of all required 
modules and links the* together into an absolute (or 
relocatable) store image. This task can be performed directly by 
the loader, because it only has to insert module numbers (table 
indices) in instructions with external addressing mode. 

The second category of instructions are the operators. They take 
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operands from the top of the stack end replace them by the 
resul t. The Lilith instruction set Includes operators for 
CARDINAL {unsigned} , INTEGER (signed! , double-precision, 
floating-point, BOOLEAN, and sot art thus tic. it directly 
reflects the operations available In Modula-2* 

The orientation towards a clean stack architecture also required 
a Cull set of comparison Instructions which generate a BOOLEAN 
result. Distinct sets are provided for CARDINAL and INTEGER 
comparison. The distinction between CARDINAL and INTEGER 
arithmetic is partially due to the desire to be able to use ail 
bits of a word to represent unsigned numbers, such mm addresses. 
It would be of a lesser Importance* if the words! xe were larger. 
However, our experience shows that It is desirable also fro* a 
purely logical point of view to declare variables to be non- 
n^atlve, if in fact a negative value does never occur. Host of 
our programs require variables of the type CARDINAL, whereas the 
type INTEGER occurs only rarely. Although using 2*s complement 
representation for negative values, addition and subtraction are 
implemented by the same hardware operations for both kinds of 
arithmetic, they differ in their conditions indicating overflow. 

Control instructions include procedure calls and jumps. 
Conditional jumps are generated for IP, WHILE, REPEAT, and LOOP 
statements. They fetch their BOOLEAN operand from the stack. 
Special control instructions mirror the CASE and FOR statements. 

Different cal Is are used for procedures declared In the current 
module and for those in other modules, tot local procedures 
there exist call instructions with short 4-bit addresses, *n 
they occur rather frequently. Calls for external procedures not 
only include in address parameter, but also a module number to 
be updated by the loader, furthermore, an Instruction Is 
provided for so-called formal procedures, I.e. procedures that 
are either supplied as parameters or assigned to procedure 
variables. 

There also exists an instruction for the transfer of control 
between coroutines. Various Instructions may cam* a trap, if 
the result cannot be computed. Such a trap Is considered like an 
interrupt requested by the processor itself, and corresponds to 
a coroutine transfer with fixed parameters. The same mechanism 
is activated by the TRAP Instruction (which corresponds to a 
HALT statement in ftodula) • 

Arithmetic operators generate traps when unable to compute the 
correct result {e.g. overflow}. Traps from CARDINAL and INTEGER 
arithmetic can be suppressed {masked) upon request] the 
programmer is then presumably aware that results are computed 
modulo 2*16. Also, load and store instructions generate a trap, 
if their address is NIL. This test requires a single micro 
Instruction only. The routines for bitmap handling generate 
traps, if ' attempting to access data outside the spec! fled 
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bitmap. All these test are quite inexpensive (but not free) , 

A test for an array index lying within the specified bounds , or 
for a value to be within the subrange ad* it ted by a variable, is 
more compl lea ted . It requl res two comparisons wi th arbitrary 
values. Therefore, the M-code contains an Instruction for an "in 
range" test. The programmer way choose to omit these tests by 
selecting a compiler option that Suppresses the generation of 
these test instructions. 

These extensive checking facilities reflect our strong belief In 
designing an Implementation (including the hardware) which 
properly supports a language's abstractions. For example, If the 
language provides the data type CARDINAL, Its Implementations 
should signal an error, if a negative result appears, just as It 
should signal an error, when a non-existing element of an array 
is identified. Omissions in this regard are to be considered as 
inadequacy in implementation. Nevertheless, the argument whether 
or not the experienced and consc ientious programmer should be 
burdened wi th these "redundant" checks remains open . Our choice 
is to give the programmer the option to suppress at least the 
more expensive checks, at his own peril. 

The category of miscellaneous Instructions contains operators 
for reading and writing data on the input/output channels, and 
four instructions used for operating on bitmaps: The DDT 
instruction (display dot) writes a single dot at a specified 
coordinate, REPL replicates a bit pattern over a rectangle - a 
so-called block - in a given bitmap. The coordinates of this 
block are relative to the specified bitmap and are given in 
terms of dot coordinates rather than 'word addresses. The BBLT 
instruction (bit block transfer) copies a source block into a 
destination block. The DCH Instruction (display character) 
copies the bitmap of a character (given Its ASCII code) from a 
font table into a specified place of a bitmap. 

The function of these bitmap Instructions could well be coded in 
Modula-2 programs. Instead, they are included as single 
Instructions represented by micro-coded routines. The primary 
reason is efficiency. The routines include checks against 
inconsistent parameters, such as blocks that do not fully lie 
within the bitmap. An essential detail is that they use the same 
convention about parameters as do regular procedures and 
operators) parameters are always passed via the stack.. Modula-2 
for Lillth offers a facility to use these Instructions as If 
they were programmed as regular procedures. This uniformity of 
parameter passing has proved to be an invaluable asset. 

Some analysis of representative programs reveals that M-code 
yields a significantly higher density of compiled code than do 
conventional Instruction sets. Compared wl th the code conpi led 
for the ubiquitous PDP-11, we obtained »n improvement factor of 
3.9. This implies that code for the same program occupies about 
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one quarter of the memory space in the (.tilth computer than In a 
PDP-11. This {actor ts noteworthy even in times of rapidly 
decreasing memory prices) 

The principal contribution to this result stews from the short 
address fields. Dominant are the counts of load and store 
instructions; they address the stack Implicitly and hence need 
only one address field. Access to local variables is most 
frequent; global variables are addressed about half *s often* 
and external variables occur rarely. Jumps account for about 
101 of all instructions, and procedure calls are about equally 
frequent. The following table displays percentage figures 
obtained fron four programs {of different authors) for the most 
frequent instruction classes. 

l-byte instr. 
2-byte Instr. 
3-byta instr. 

toad immediate 
Load local 
Load global 
toad indirect 

Store local 
Store global 
Store Indirect 

Operators 
Comparators 
Jumps 
Calls 

Total counts {100%) 11052 7370 7936 2814 

Instructions are executed by a micro-coded program called the 
Interpreter, which may well be expressed in Hodula; this 
algorithmic definition of the Lilith instruction set has proved 
to be extremely valuable as Interface between the micro- 
programmer and the compiler designer. 

9. The Lilith hardware structure 
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The following requirements determined the design of the hardware 
most significantly.* 

- fast implementation of the H-code interpreter* in particular 
of *its stack architecture* 

- the need for efficient Implementation of the bitmap 
instructions which involve a large amount of bit pushing and 
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partial word accesses (bit addressing) . 

- high bandwidth between memory and display Cor continuous 
refreshing. 

- the desire for a staple structure with a relatively large, 
homogenous store, 

- ease of serviceability. * 

The computing power required by the bitmap instructions 
eliminated the choice of a one-chip processor, An even stronger 
reason against such a choice was the project's purpose to find a 
hardware architecture truly sui table for use with code compiled 
from a high-level language. The btt-slice processor Am290l 
offered an ideal solution between a one-chip processor and the 
complete design of a unit built with SSt and MSI components, it 
allows for a basic instruction cycle that is about a fourth of a 
memory cycle US* ns) . This Is a good relation considering the 
average amount of processing required between memory accesses, 

The processor is built around a 16-blt wide bus connecting the 
arithmetic-logic unit (ALU) with the memory for transfer of data 
and addresses. Also connected are the instruction fetch unit 
(IFU), the disk and display controllers* and the interfaces to 
the standard low-speed I/O devices keyboard, House, and serial 
V24 (RS232) line. Bus sources and destinations are specified in 
each micro- instruct Ion by 4-bit fields which are directly 
decoded. The bus uses trl-state logic. 

The refreshing of the full screen requires a signal with a 
bandwidth of 13 HHz, if interlacing and a rate of SB half 
pictures per second is assumed. This Implies that on the average 
one 16-bit word has to be fetched every 1.) us, which implies 
that memory would be available to the processor about 50% of the 
time. This unacceptably low rate calls for a memory with an 
access path wider than IS bits. It was decided to Implement a 
64-blt wide memory. 

A third candidate for direct memory access is the instruction 
stream. Like the display, this port requires sequential reading 
only and therefore can benefit from a wide access path feeding 
an internal buffer. This organization reduces the average time 
that the memory is devoted to display and instruction fetching, 
i.e. where it is Inaccessible to the data port of the main 
processor, to about 10%. The overall structure of the Lilith 
hardware is shown in Fig. 9. Its heart is the microcontrol unit 
{HCU) which contains the clock and controls the instruction 
stream. 

9.1 The micro-control unit 



The micro-control unit (HCU) consists primarily of a memory for 
the microcode, a micro- Instruction register (HIR) , an address 
tncrementer , and some decoding logic. A micro- Instruction 
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consists of 40 bits; Its formats are shown tn Fig. If. The 
Micro-instruction address is a 12 bit integer, hence the memory 
may have at most 4K locations. Actually, only 2K are used and 
implemented as a read-only store (ROM). An additional 2tt RAM nay 
be supplied. Approximately IX is used by initial Ixatton routines 
(bootstrap loader) and the H-code interpreter, and IK is needed 
lor the bitmap routines and the floating-point Instructions. 

fig. II shows the structure of the micro-control unit. The nest 
instruction's address is taken from one of several sources i 

- the incrementer (normal case) 

- an address stack (subroutine return) 

~ the current instruction (Microcode jump) 

- a table of addresses of routines which correspond to M-codss 

- according to a pending interrupt request. 

The addresses are generated by Am29H bit-slice controllers 
which contain an incrementer and a short stack for subroutine 
return addresses. For jumps, the next address Is supplied from 
sources external to the 2911. Conventional jumps take the 
address directly froM the instruction register (MIR). Exceptions 
are the jumps to the start of the microcode routine representing 
the next M-code instruction. Here the address is taken from a 
ROM which maps the 8-bit M~code into a 12-bit address. This 
exception Is signalled by a micro-instruction whose source field 
value causes the address to be selected froM the map ROH. An 
exception to this exception occurs if an (unmasked) Interrupt 
request Is pending, in which case the next address is the fixed 
number assigned to the requesting line. Thereby the M-code 
sequence can be interrupted without requiring any additional 
micro-instructions, and the transition to the next Micro- 
instruction routine is Initiated by a single instruction at the 
end of each routine. 

A tag bit of each micro-instruction determines whether It Is to 
be interpreted as a regular or as a jump instruction. During 
execution of the latter the main processor is disabled. Jumps 
are conditional upon the state of the main processor's condition 
code register determined by the ALU's result computed during the 
previous cycle. 

9.2 The arithmetic logic unit 



The ALU's heart is a 2981 bit-slice processor. It contains the 
logic for integer arithmetic (addition) and for bit-parallel 
logical operations, and a set of 16 fast registers. Half of them 
are used for global state variables of the M-code Interpreter, 
the others as work registers local to each microcode routine. 
The 2901 core is augmented byf two facilities dictated by thi 
requi rements of the stack architecture and by the bitmap 
routines; a Cast stack memory and a barrel shifter (Fig. 12). 
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The fast stack is a store of 16 locations (16 bit wide) and an 
address incrementer/decrementer. This memory holds the 
intermediate resul ts dur ing evaluation of expressions and 
statements, and must be regarded as logically being part of the 
(ma In) stack, but physically separate . Load instructions fetch 
data from the (main) stack In memory and push them onto the fast 
expression stack. Store instructions pop the expression stack 
and deposit data in main memory. As a consequence* each such 
instruction takes a single main memory cycle only. Ho re 
precisely, data loaded from and stored into the main stack are 
transferred to and from a register in the 2901 processor itself* 
while during the same cycle this T-reglster is saved (or 
restored) into (from) the expression stack: 

Load: push T onto stack/ Bus -> T 
Store* T -> Bus; pop stack into T 

Operations such as addition, comparison, AND, OR, etc. , can also 
be performed in a single cycle, because both operands are 
immediately accessible: 

Add: T + top stack -> T* pop stack 

The hardware represents a genuine stack In so far as the current 
stack top Is the only accessible element* and that its address 
Is inaccessible to the programmer. This address is generated by 
a 4-blt up/down counter and directly fed to a 16x16 high-speed 
HAM. A slight complication arises because address Incrementation 
for a pop must occur before the data fetch* whereas the 
decrementing for a push must occur after the store. However * 
both address counting and data access must be performed during 
the same clock cycle. The solution is found in using an extra 
adder and to operate according to the following scheme: 

push: DECfx)f S(x+H s- data 
pop: INC(x)j data :- S[x1 

The circuit of the entire stack mechanism is shown tn Fig. 13. 
It may be surprising that the fast stack has a depth of only 16. 
In practice* this proved to be ample. It should be noted that 
the compiler can keep track of the number of stack locations 
loaded, and hence no runtime stack overflow can occur, nor need 
it be monitored. The stack is empty after execution of eaclf 
statement. In the case of function procedures* the expression 
stack has to be saved into the main stack before* and restored 
after the call. Special M-code instructions are provided for 
this purpose* 

The barrel shifter is prefixed to the input lines of the 2981 
processor. It allows the rotation of data by any number of bit 
positions between § and 15. Together with the logical 
instructions (AND* OR) it provides the necessary speed for 
partial word handling extensively used in all bitmap operations. 
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It is designed such that it can slso generate Masks of to 15 
bits in one cycle. The shift count (nask length) can either be 
taken froM a field in the Micro-instruction itself, or CroM a 
special 4-bit shift count register, also contained in the ALU. 

9.3. The memory 

The MCMory is built with I6K dynamic RAM chips distributed on 
four boards, each being organized as a 16K*32 block. For 
reading, 32 bits are accessed siMultaneously froM two of the 
four boards. Multiplexors select 8 of the 32 bits for output to 
the processor bus via the so-called CPU port. For writing, the 
same connection is used, and the data are fed to four chips in 
parallel, of which only one is enabled through the chip select 
signal. Fig. 14 shows the scheMe for two boards; together they 
represent a 64KM6 bit MeMory for writing, or a I6K*64 bit 
MeMory for reading.. 

The choice of a 64-bit wide access path guarantees the necessary 
memory signal bandwidth, but it also poses significant 
electrical problems that should not be underestimated. Their 
Mastery is an order of Magnitude More difficult than the 
handling of conventional 8-bit MicrocoMputer systems. 

Processor and display operate asynchronously. Hence, an arbiter 
MechaniSM is needed for controlling MeMory access. It can easily 
be extended to accoiuiodate several instead of only two ports. 
Each port is assigned a fixed priority, and the request from the 
source' with highest rank among those pending is honoured. Fig. 
15 shows the circuit used; it contains cascaded priority latches 
that retain posted requests. Also shown Is the circuit used for 
the synchronization of a requestor (the CPU port as mn example) 
and the memory, which operate on separate clocks. The priority 
latch is common to all ports, the other parts are Individually 
replicated for each port. Fig. 16 shows the signal timing: If 
the port requests a memory cycle, the bus data, representing an 
address, are latched in the meMory address register MAR, the 
port is marked busy, and the request is passed on to the 
arbiter. Unless a request with higher priority is present, the 
signal CPU.SEL goes high, indicating that the MeMory cycle now 
started belongs to the CPU port and MAR is gated to the address 
lines. When terminated, the signal CLR resets the busy latch, 
indicating to the polling CPU that Its request has been served. 

9.4. The Instruction fetch unit 



Instructions are fetched via a separate Memory port controlled 
by the instruction fetch unit (IFU). This unit contains its own 
address registers (PC,F) and an 8-byte buffer. The buffer can be 
regarded as a small cache memory and is particularly effective 
because access is mostly sequential. Reloading occurs when 
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either the buffer Is empty, or when a new address Is fed to the 

PC by a control Instruction, the IFU contains its own address 

tncrementer (the PC register Is a counter) and an adder forming 
the sun of the PC and P values. This adder Is 18 bits wide, A 

byte Is fetched from the buffer and the address Is Incremented 

whenever the micro-controller executes a jump enabling the map 

ROM. Pig. 17 ts a block diagram of the IPO. 

9.5. The House 



The House is a device to designate positions on the display 
screen. It operates on the principle that movements of the 
operator * s hand on his desk are sensed, rather than on the 
recording of precise, absolute coordinates. A cursor is 
displayed (by appropriate programming) on the screen, changing 
its position according to the signals received from the Mouse. 
Hence, positioning of the cursor can be as accurate as the 
display's resolution allows, without requiring a high-precision 
digitizer device. The Mouse Is also equipped with three 
pushbuttons (eyes) ar.-i is connected to the keyboard by a thin 
tail; hence Its name. 

The movements are transmitted via a ball 'to two perpendicular 
wheels, whose "spokes" are seen by a tight sensor. The direction 
of their turning is perceived by sampling two signals received 
from spokes which are offset. If we combine the two binary 
signals and represent them as numbers to the base 4, the wheels* 
turning results in sample value sequences 0,2,3,1,0, ... or 
0,1,3,2,0, ... depending on the sense of their rotation (see 
Fig. IS). 

The interface for the House contains two counters for the x- and 
y-coordlnates. They are incremented or decremented whenever a 
transition of the Input signals occurs as indicated by the two 
above sequences. A state machine registers the signal values 
sampled at two consecutive clock ticks; a ROM Is used to map 
them Into the necessary counting pulses. 

9.6. The Monitor 



The Monitor is an additional unit which Is not present In the 
computer under normal circumstances, but for which nevertheless 
a permanent slot is reserved, such that it can be Inserted any 
time. It represents a small computer of Its own, and It has the 
capability to take full control over the Liltth processor. It is 
therefore used for servicing when the Liltth hardware falls, and 
It played a most crucial role during the entire development and 
debugging phases of the ttlith computer. 

The Monitor's heart is a Motorola 6802 one-chip microprocessor, 
augmented by a 2K byte ROM and a 4K byte RAH, Interface 






registers to the Lilith hardware, and a serial line Interface to 
a terminal (UART) . Its block diagram is given In rig, 19. the 
Monitor can 

- read the Microinstruction register (KIR) 

- supply the next Microinstruction (disabling MIR) 

- read the micro-program counter (2911) 

- supply the next instruction address (disabling 2911) 

- read the processor bus 

- feed data to the processor bus 

- disable the processor clock (halt) 

- send clock pulses (single or Multiple step) 

For debugging and servicing, an elaborate set of programs wai 
developed. In addition to a standard "operating system" residing 
in the ROMs, test programs can be loaded into the RAM from a 
terminal. We extensively used an HP 2645A terminal with tape 
cassettes as our prog r a* library store. When a new Lilith 
Machine is to be tested, the Monitor is used to first test the 
MCU board, then to test the ALU board, thereafter the Menory (in 
conjunction with MCU and ALU), then the IFU, and finally the 
interface boards. The Monitor not only Made a front panel 
superfluous, but allowed the construction of the entire coMputer 
with the aid of only *n oscilloscope and, very rarely, a small 
logic state analyzer. 

9.7. The physical layout 

The Lilith computer is designed to fit beside or underneath a 
table on which the lS*~display, the keyboard, and the Mouse are 
placed. The cabinet has a height of 74 cm; It is 43 cm wide and 
55 cm deep. The disk cartridge is accessible froM the front. 

The electronic components are placed on II boards housed in a 
rack with dimensions 42*35*31 cm. One board each contains the 
Microcontrol unit, the ari thmetic-logic unit, the processor part 
and interfaces to keyboard. Mouse, and serial data line, the 
instruction fetch unit, the display Interface and the disk 
interface. Four boards contain the Main memory. Another board 
slot is reserved for a 2K*4i Microcode RAM, one for the Monitor, 
and 5 slots are free for future experiments with other units or 
interfaces. This Makes the computer suitable as an object for 
experimentation on the hardware as well m* the software level. 

The remaining space in the cabinet is taken by the disk drive 
and the power supply. Conventional linear power supplies were 
built after several disappointing experiments with Modern 
swi tching power suppl ies that offer a Much improved efficiency. 
They turned out to be unable to cope with the Cu rope an 220 
Volts. 
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) 8. Conclusions 



The personal computer leads to an entirely new computing 
environment. Due to the high bandwidth of Information between 
its user and his tool, a close interaction is possible that 
cannot be provided by a central, remotely accessed facility. The 
personal computer Is much more than an "intelligent terminal", 
because It puts the computing power near the user . h 
particularly attractive feature is Its constant availability, 
and consequently the owner's independence of a computing 
center's service hours. 

Interactive usage is of particularly high value in the 
development of software, where text editing, compiling, and 
testing are the prime activities. In our experience, a personal 
computer increases the effectiveness of a competent software 
engineer by an order of magni tude. 1 stress the attribute 
"competent" , for he needs the wt sdom to leave his tool and 
retreat to quiet del iberatlons when deeper problems of 
a Igor ithmlc design appear . For the less competent engineer , the 
personal computer ampl if ies the danger of: seduction to 
programming by trial and error ("hacking") , a method that is 
unacceptable In professional software engineering . 

It has now become a widely accepted view that the software 
engineer's notational tool must be a high-level programming 
language. When large, complex systems are the objective, the 
tool must support modularization and the specification of 
interfaces. We have designed the language Modula-2, a more 
modern version of Pascal, with the principal addition of a 
module structure. Our implementation connects this feature with 
the facil 1 ty of separate compilation. Separate compilation, 
however, is not independent compilation. On the contrary, the 
compiler must fully check the consistency of the separately 
compiled modules as if they were written as a single piece of 
text. The separation of global modules Into definition and 
implementation parts makes It possible to define those aspects 
of a module that are significant for its clients apart from 
those that are private to its implementation. It reinforces the 
strategy of first breaking down a planned system into modules, 
then to define their interfaces with the goal to keep them 
"thin", and finally to let the members of the programming team 
implement the modules with relative independence. 

The exclusive use of a high-level language makes it possible to 
design a computer architecture without regard of its 
suitability to assembler coding. The resulting architecture Is 
organized around a stack . The instruction set is . designed to 
provide a high density of code, largely due to the use of 
variable address length. 

It Is particularly attractive to design such an architecture and 



fc- 



- 32 - 



instruction set, if no conventional computer must b* used for 
its interpretation. Me have therefore also undertaken the design 
of a hardware system with the purposes to Interpret this code 
efficiently and to accomodate the use ol a high-resolution 
display. The latter requires a high memory bandwidth and bursts 
of fast conputatlon* The implementation of a mlcrocoded 
Interpreter and the inclusion of a few special instructions for 
bitmap handling appears to be an ideal solution. These 
instructions correspond to mlcrocoded routines that per Cora the 
necessary bit-pushing with greatest efficiency. 



As an experiment to integrate the design of a programming 
language ~ the software engineer's notational tool - the 
development of its compiler and environment* the design of a 
computer architecture and instruction set, and the construction 
of the hardware - the software engineer's physical tool - the 
project has been successful and exciting. The resulting system 
is, of course, not without Its deficiencies. Our consolation Is 
that. If we did not know of Items that should have been done 
differently, we would not have learned through our research. 
Also, the project had to be conducted with severe restrictions 
on manpower. This had the benefit that no significant management 
problems were encountered. 

As far as the hardware Is concerned, an additional constraint 
was the limited availability of modern technology. It was 
therefore decided to rely on commercially available TTL chips 
only, apart from HOS technology for the memory. The integrated, 
top-down design from software to hardware outlined by this 
project, Is especially relevant in view of the future role of 
VLSI technology. Its unlimited possibilities require that the 
designer obtain new criteria guiding his objectives. The top- 
down approach crossing the soft/hardware boundary tells the 
hardware designer what is needed rather than the hardware 
customer what is available. An aspect of this project that we 
were unable to tackle was the design of LSI chips representing 
the essential units of the Llllth computer. Incorporating the 
unconventional aspects of its architecture. The chip count (as 
well as power supply problems) could thereby have been reduced 
quite drastically. We hope that someone better equipped for the 
task will pursue this challenge. 
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Appendix 1 

Th« H-code interpreter 

The fallowing Modula-2 program Interprets H~code instructions 
and serves as a high-level definition ol the Llllth computer's 
instruction set and architecture, A few comments are necessary 
to cover details that are not fully described by the program. 

1. The array variables stk and code stand for the date end 
program stores respectively. We assume that on en actual 
computer they represent the SAME physical memory. The array 
indices then denote memory addresses. Access to the code 
involves the use of the base address W {and an 18-bit wide 
addition) . - 

2. All checks against arithmetic overflow, storage overflow, and 
access with value NIL are omitted from the program in the 
interest of clarity and in order not to obscure the essentials 
of the interpretation algorithm. 

3. Certain instructions are explained in loose English instead 
of precise Hodula statements. Among them are the bitmap handling 
Instructions, which actually constitute fairly complex 
algorithms, and also operations like shifts, packing, and 
unpacking, which are considered as primitives, end hence not to 
be defined contortlously in terms of even lower primitives. 

4. The functions low(d) , htgh(d) , and palr(e,b) ere Introduced 
to denote selection of a part of a double word end construction 
of a double word. The functions Dtrunc and Of lost denote 
conversion of floating-point values Into double word Integers 
and vice-versa. All these functions are NOT available In Module- 
2. Also, sets of the form (m..n) are used, although proper 
Modula-2 does not allow expressions to be used within set 
constructors* 

5. The detailed specification of x/o instructions is suppressed. 
It is considered not to be part of the general H-code 
definition, but should be al lowed to vary among different 
implementations according to the available hardware. This Is 
particularly true for the instructions OSKR, DSKW, SETRK used 
for accessing the disk. 

6. The interrupt mechanism Is described in a rather loose manner 
and requires additional explanation: At the start of each 
interpretation cycle, the Boolean var labia R£Q determines 
whether or not an interrupt request should be honoured. REQ 
means "at least one of the unmasked Interrupt lines (numbered 
8.. .15) is low*. If we denote the request lines by the set 
variable ReqLlnes and the presence of a request on line 1 by 
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'NOT (i IN ReqLines) 



"» then REQ can be expressed as 



REQ - (ReqLines + Hask I {8 



15}} 



The value Mask Is the union of the mask register H and a 
variable called DevMask {Mask * H + DevHask) . This global 
variable al lows a program (typically the operating system) to 
shut out any Cor all) devices from interrupting . In the Lil i th 
computer, DevHask is allocated In main memory at location 3. The 
value ReqNo determines the interrupt line whose request is being 
accepted. Xt determines the transfer vector used by the TRANSFER 
operation. The value ReqNo is defined as the maximum I such that 
"NOT (i IN ReqLines + Hask). 



Table of instructions 
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100 



140 



200 



240 



300 



340 






110 


LLW 


LGW 


LSW0 


LSW 


READ 


FORI 


NOV 


1 


Lit 


LLD 


LGD 


LSN1 


LSD 


WH X JT IS 


FOR? ' 


CHP 


2 


LI2 


id#n 


LGW 2 


LSW2 


LSD0 


DSKR 


ENTC 


DDT 


3 


(.13 


LED 


LGW 3 


LSW3 


Lxrw 


DSKW 


EXC . 


REPL 


4 


L14 


LLW4 


LGN4 


LSW4 


LSTA 


SETRK 


TRAP 


BBLT 


5 


LIS 


LLW5 


LGW 5 


LSW5 


LXB 


UCHK 


CMK 


DCH 


6 


LI6 


LLW 6 


LGW 6 


LSW6 


LXW 




CHKZ 


UNPK 


7 


LI7 


LLW7 


LGW 7 


LSW7 


LXD 


SYS 


CHICS 


PACK 


10 


LIS 


LLW8 


LGW8 


LSW8 


DADD 


ENTP 


EQL 


GB 


11 


L19 


LLW9 


LGW9 


LSW9 


DSUB 


EXP 


NEQ 


GB1 


12 


LI10 


LLW 10 


LGW IS 


LSW10 


DMUL 


ULSS 


LSS 


ALOC 


13 


LI11 


LLW 11 


LGW11 


LSW11 


DDIV 


ULEQ 


LEQ 


ENTR 


14 


LIU 


LLW 12 


LGW 12 


LSW12 




UGTR 


GTR 


RTN 


15 


LI13 


LLW 13 


LGW13 


LSW13 




UGEQ 


GEO 


CX 


16 


LIU 


LLW 14 


LGW14 


LSW14 


DSHL 


TKri . 


ABS 


CI 


17 


LI15 


LLW IS 


LGW15 


LSW15 


DSHR 


RDS 


NEG 


CF 


20 


LIB 


SLW 


SGW 


S5W0 


SSW 


LODFW 


OR 


CL 


21 




SLD 


SGD 


SSW1 


SSD 


LODFD 


XOR 


CL1 


22 


LtW 


SEW 


SGW 2 


SSW2 


SSD0 


STORE 


AND 


CL2 


23 


LID 


SED 


SGW 3 


SSW3 


SXFW 


STOFV 


COH 


CL3 


24 


LL* 


SLW4 


SGW4 


SSW4 


TS 


STOT 


IN 


CL4 


25 


LGA 


SLWS 


SOWS 


SSW5 


SXB 


COPT 


LIN 


CL5 


26 


LSA 


SLW6 


SGW 6 


SSW6 


w An 


DECS 


H5K 


CL6 


27 


LEA 


SLW7 


SGW7 


SSW7 


SXD 


PCOP 


NOT 


CL7 


30 


J PC 


SLWS 


SGW8 


SSW8 


FADD 


UADD 


ADD 


CL8 


31 


JP 


SLW9 


SGW9 


SSW9 


FSU8 


USUB 


SUB 


CL9 


32 


j pre 


SLW 10 


SGW10 


SSW10 


FHUL 


UHUL 


NUL 


CL11 


33 


JPF 


SLM11 


SGW11 


SSW11 


FDXV 


ODIV 


DIV 


CL18 


34 


JPBC 


SLW12 


SGW12 


SSW12 


PCNP 


UHOD 




CL12 


35 


JPB 


SLW13 


SGW13 


SSW13 


FABS 


ROR 


BIT 


CL13 



36 
37 



ORJP 
ANDJP 



SLWH 
SLW15 



SGWH 
SCW I 5 






SSWU 
SSW1S 



PNEG 

rrcT 



5HL 
SHR 



HOP 
MOW 



CLM 
CLI5 



Reserved 1 oca t tons; 




i 

2 

3 
« 

S 
6 

16,17 
29,2) 
22,23 



(P-reglster of aodule 0) 

(initialization flag of nodule •) 

{string pointer of Module 0} 

device mask 

P-register 

saved P-reglster 

boot flag 

trap vector 

interrupt vector for line 8 (clock) 

interrupt vector for line 9 (disk) 



36,37 interrupt vector for line IS 
40. .177 data frame table 



MODULE Interpreter 



CONST tic 
dft 



(•N.Wirth, Ch.Jacobij Peb.BI*) 

- 16B; (*trap location adr*) 

■ 4fBj (*data Crane table adr*) 



VAR 



(*global state variables*) 

PC; CARDINAL j 

IRt CARDINAL} 

P: CARDINAL} 

C: CARDINAL} 

H: CARDINAL} 

Li CARDINAL} 

St CARDINAL} 

P; CARDINAL} 

Hi BITSET, 

BEQs BOOLEAN} 



ReqNo: CARDINAL} 



(•prograst counter*) 
(•instruction register*) 
(•code fraae base address*) 
(•data frane base address*) 
(•stack Unit address*) 
(•local segment address*) 
(•stack pointer*) 
(•process base address*) 
(•process interrupt Mask*) 
(•interrupt request*) 
(*reguest nue.be r, 8.. 15*) 



(•auxiliary variables used over single instructions only*) 
I, J, kt CARDINAL} 

sz, adr, low, hi i CARDINAL} (*used in FOR, SNTP, PCOP*) 
sb, db, sbad, dbad, foj CARDINAL; (•display handling*) 

It t jf * HmAIaJ 



stk: ARRAY {0..177777B] OP CARDINAL} 

MODULE InstructionPetch; 
IMPORT F,PC, 
EXPORT next, next2} 



(•data store*) 



VAR code: ARRAY [8..77777B] OP (0..255I; 






PROCEDURE next() : CARDINAL; 
BEGIN 

INC(PC); RETURN codeH*F+PC-l J 
END next; 

PROCEDURE next2(): CARDINAL; (*get next two code bytes*) 
BEGIN 

INC{PC, 2); RETURN code[4*F+PC-2 J *400B + code(4*F+PC-H 
END next2; 
END InstructionFetch; 

MODULE ExpressionStack; 

EXPORT push, pop, Dpush, Dpop, empty; 

VAR sp: CARDINAL; 

a: ARRA* t B . .151 OF CARDINAL; ^expression stack*) 

PROCEDURE push{x: CARDINAL); 
BEGIN «(sp| t- Xf INC(sp) 
END push; 

PROCEDURE pop() i CARDINAL; 
BEGIN DEC Up) J RETURN(aJspJ) 
END pop; 

PROCEDURE Dpush(d: REAL); 

BEGIN a|spl :» highfd); INCfsp); a[sp} ;- low(d) ; INCfsp) 

END Dpush; 

PROCEDURE Dpop(): REAL; 

BEGIN DEC{sp,2); RETURN palr(a[sp], atsp+lj) 

END Dpop; 

PROCEDURE enptyf) : BOOLEAN; 
BEGIN RETURN sp - 
END empty; 

BEGIN sp i- 0; 

END ExpressionStack; 

PROCEDURE *ark<x: CARDINAL; external! BOOLEAN); 

VAR t t CARDINAL; 
BEGIN t :* S; 

stk(S| :- x; INC(S)j {*static link*) 

Stk[S| :- L; INC(S); (*dyna«ic link*) 

IF external THEN 

stk(S) ;- PC+1000B0B ELSE stk(S) ;- PC 

END ; 

INC|S,2); L :- 1 
END mark; 

PROCEDURE saveExpStack; 
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VAR c* CARDINAL} 
BEGIN c t* ij (*expresslon stack counter*) 

WHILE NOT eaptyO DO 

stk|S] ;- popOi INC(S); INCic)} 

ENO i 

stk|S) :- C| INC(S) 
END saveExpStack; 

PROCEDURE restoreExpStacki 

VAR c; CARDINAL} 
BEGIN DEC(S); c j« stk[S}j 

WHILE c>0 DO 

DEC(c); DEC(S); push(stkfS)) 

END 
END restoreExpStackj 

BEGIN saveExpStack; 

stk(p ) j« Gi stk(p+}| i* Li 

Stk(P+2] t* PC| stktPOJ t* CARDINAL(K)} 
Stk{P+4) !* Si stk(PtS) t- H+24i 
(* stk(p+6) is reserved Cor error code *J 
{* stkjp+71 Is reserved tor error trap »ask *) 
END saveRegsi 

PROCEDURE rsstoreRegsfchangeMaskt BOOLEAN)} 
BEGIN 

G :» stk(p), P *=. stkiGli 

L i» stk|P+lli PC :- stk(P+2l; 

IP changeHaak THEN N t« B ITSET< sLk (Pt3 )> END i 

S t* stk(Pt4)i H j- stk|p+5l-24f 

restore&xpStack 
END restoreRegsi 

PROCEDURE Transfer (changeMaski BOOLEAN j to, front CARDINAL)} 

VAR j* CARDINAL; 
BEGIN 

j i» stk(to)j saveRegsi stkCCroa) ;- P} 

P :• ji restoreReqs(changeMask) 
END Transfer; 

PROCEDURE Trap(ni CARDINAL)} 
BEGIN 

If NOT (n IN BXTSET(stk[P+7H) THEN 

stk|Pt6) :- n; 

Transfer (TRUE, tic, tlc+l) 
END 
END Trap; 

BEGIN (• reddBootfile *) 

P z* stk(4); restoreRegsiTRUEl j 
LOOP 

IP REQ THEN Transfer (TRUE, 2*Req«o, -"Reqtto+1 ) END j 
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IR :■ 
CASS 

BB . 

2»Bt 
22B: 
23Bi 



24B 
258 
26B 
278 

30B: 



31B: 
32Bj 

33B: 
34B: 

35B: 

3€8: 

37Si 

408; 
4IB; 



next (1 j 
It or 
17B: (*LI8 - LI15 load Immediate*} push(IR MOD 16) I 

•LIB load Immediate byte*) push(nextO) 1 

*LIW load immediate word*) push(next2(} ) I 

•LID load immediate double word*) 
push(next2(Hf push(next2 f ) ) I 

*LLA load local address*) push(L+next( ) ) | 

*LGA load global address*) push (C+next( ) ) | 

*LSA load stack address*} push(pop[)+next() ) | 

*LEA load external address*) 
push(stk(dft+nextO j+next{) ) | 

*JPC jump conditional*) 
F popn » • THEN PC t- PC + next2() 
ELSE INC (PC, 2) 
END | 

*JP jump*) PC !- PC + next2() I 

*JPFC jump forward conditional*) 

P pop() - 8 THEN PC :» PC + next() ELSE INC (PC) END } 

*JPF jump forward*) PC :» PC + next() | 

*JPBC jump backward conditional*) 

F pop() - B THEN PC i« PC - nextf) 8LSE IHC{PC) END | 

*JP8 jump backward*) PC :- PC - next() I 



*08JP short circuit or *) 

r popO - * THEN INC (PC) 

ELSE push(l)| PC 
END | 

•ANDJP short circuit and *) 
p pop() ■ 9 THEN push(l)} PC 
ELSE INC (PC) 
END | 

*LLW load local word*) 



PC4next() 



PC+next() 



push(stk[L+next() ) ) I 



*LLD load local double word*) 
:»L+nextOl push(stkf I J ) | pushfstkfi + U) | 



42Bt ('LEW load external word*) 
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push(stk[stk{dft+nextO)+nextOU I 

43B; |*LED load external double word *) 
1 :- stk[det+next{)l+nextOi 
pusMstMUJi push(stk(l+U> I 

448 .. 57Bi (*U.W4-LU*15*) pushl«tk(L + (IR HOD 16)1) I 

6IB* (*SLW store local word - ) stk(L+n«xt()) i» pop() | 

61B: (*SLD stor* local double word*) 

i i- ttn*Mt|)i stk[itl)-t" pop(); stk|ij i» pop() I 

62B; (*SEW a tor a external word*) 

stk|stkfdft+next() )+next{) ) t* popO I 

63B; t*SED stora axtarnal doubla word *) 
1 :- 8tk|dEt+neittU ]*n«xtO I 
stkli + U i- popUl stkUl i- pop() I 

648 .. ?7Bt (*SLW4-SLW15 stora local word*) 
stk[L+(Ift MOP 16)J *■ pop() I 

IIBBt (*LGW load global word*) push(stkfG*next<) |) | 

I01B: |*LCD load global doubla word*) 

1 ;- next()+G, pushtstk|l])i push(*tk|l+l |) \ 

IB2B .. U7Bs (*LGW2 ~ LGW15 load global word*) 
push(stk[G + (IR HOD 16))) I 

!2§Bi (*SGVf stora global word*) stklG+next{)t *■ P°pO t 

121B; (*SGD stora global doubla word*) 

i :-G+next()f stk{t+l| :- popU* stk(i) i« pop() ) 

122B .. 137Bt (*SGW2 - SGVM5 stora global word*) 
stk|G + (IR HOD 16)) :- pop() | 

I40& .. 1S?Bt (*(.SWi - LSW1S load stack addrassad word*) 
pusMstMpopO + flR MOD 16))) | 

16IB .. 1778: (*SSWI - SSW15 stora stack-addrassad word*) 
k ;» pop(); i :- pop{) + UR HOD 16)» stMH *• k | 

2i>Bt (*LSW load stack word*) 

f s« pop() *• nextUi push(stk(t|) | 

2B1B: (*LSD load stack doubla word*) 

t i- popt) ♦ naxt()f push(stk(i))| push(stkti + t 1) | 

2d 38: |*tXfW load Indexed fraae word*) 

k :» pop() + pop()*4j pu$h(stk{k)) | 
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202»t (*LSOi load stack double word*) 

I t- pop()j push(stkfi|)i push(stk(U1]) | 

20401 |*LSTA load string address *) push{stk(G+2)+next() ) I 

205B: {*LX8 load indexed byte*) 

i i- popO* j J" popOi k :■ stk[j + (t DtV 2)1; 
IF 1 HOD 2 - i THEN push(k DIV 4000) 
ELSE push | k HOD 400B) 
END I 

206B: (*LXW load Indexed word*) 

1 :» popO+popOl pusfifstklU) I 

207B: (*LXD load indexed double word *) 

I ;- 2*pop()+pop{); push(stk[ I J ) ; push(stk{ l+l 1 ) | 

210B: (*DADD double add. Subsequent operators Cor double 
words denote unsigned fixed-point arithmetic, 
although the program shows REAL operands*) 
y i* DpopOj X :» DpoptJ; Dpush(xty) | 

21 IB: (*DSUB double subtract*) 

y t* Dpop{)| x :* DpopUi Dpush(x-y) I 

212B: (*DHUL double multiply*) 

i j» popOj t :■ pop()i (* x t» i*j *) Dpush(x) J . 

213B: (*DDIV double divide*) 
j ;- popU. * :■ DpopOi 
C* k :- x DIV j; i :» x HOD j *) push<i) t push(k)* | 

216B: (*DSHL double shift left*) 

x !» DpopOj (*shlft x left 1 bit*) Dpush(x) | 

217B: (*DSHR double shift right*) 

x :« DpopOi (*shift x right I bit*) Dpush(x) I 

220B: |*SSW store stack word*) 

k :> popOl i *• popt)+next()i stkflj t» k | 

22IB.* (*SSD store stack double word*) 

k t» pop()t j| :" popt)J * !» pop()+nextO> 
stk|il i- jj stk[l+1| :» k | 

222B: <*SSD0 store stack double word*) 

k :« popOl j :« pop{); I s» popOl 
stk[t) i- j| stk[i+l| :- k ) 

223B: |*SXFW store Indexed frame word*) 

1 i» popOr k t> pop() + pop()*4; stk{k) :- t | 
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224B: (*TS test and set*) 

i ; - popCli push(stk[i| >j atk(l) i« 1 | 

225Bt (*SXB store indued byte*) 

k :- popdi t i« popUl j i- pop() + (1 OIV 2); 
IP i NOD 2 - § THEM 

UtklU I* k*4MB * (atktj) HOD 4«§B) 
ELSE stk(jl i- (stk(j) DIV 4Mft) * 4MB + k 
END | 

226B: <*SXW store indexed word*) 

k :* pop()i I t» po0t)+pop()j stk|l| t- k | 

227B: (*SXD store indexed double word*) 

k :- popOf j *- POPO* 1 i» 2*pop{)+pop()f 

stkiij i« ii «tk|i+i) i- it i 

23iSt (*FAOD floating add*) 

y i- DpopOi x t- OpopUl Dpush(x*y) I 

231B* |*PSUB floating subtract*) 

y :- DpopOr x i" DpopUi Opustt|x-y) | 

232Bi (*PHUt floating Multiply*) 

y ;- DpopC)} x i" DpopOi Opush|x*y) I 

233Bt |*FDIV floating divide*) 

y :- DpopOi x ;- DpopUi Opush(x/y) | 

234B1 (*FCHP floating co*pare*) 
X s» Dpop()| y-;» DpopOi 
IF x > y THEM pusMi); push(l) 

ELSIF X < y THEN pushCUl push(t) 

ELSE push (I), push(fl) 
END | 

2358; (*FABS floating absolute value*) Dpushf ABS(DpopOU I 

236Bj (*FN£G floating negative*) Dpush (-Dpop( ) ) | 

237B: {*f¥CT floating functions*) t i- nextOl 
IF i-i THEN Dpush ( FLOAT (popOU 

ELSIE i>l THEN Dpush(PFloat(DpopU ) I 
ELSIF i-2 THEN push (TRUNC <Dpop( ) ) ) 
ELSIF i-3 THEN Dpush{Dtr unc (Dpop( | , pop())) 
END | 

24IB; (*READ*) 1 i- popOl k ;- popOf 

I* stkti) t- input fro*, channel k *) | 

241B: (*NRIT£*) i i- pop()| k t- popOf 

I* output I to channel k *) | 
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24261 
24 31tt 

244B: 
245B: 

247B: 
2SB8: 

2S1B: 
252B; 

2S3B: 

2MB: 

255B! 

256B: 

257B: 

26 BBs 
261B: 

262B: 
263B; 

264B: 

26SB: 



*DSKR disk rt*dM I 

•DSKW dtak writ**) t 

•SETRK set disk track*) | 

*UCRK*J k :■ pop()f j :» pop(); i := popO ; push(H* 
P (I < j) OR (1 > k) THEN TrapH) END I 

*SYS rarely used system functions*} I 

*ENTP entry priority*) 

tkfL+31 t- CARDINAL(M); * t* [«..nexti)-l| | 



*EXP exit priority*) 



BITSET(stk[L+3]) | 



*ULSS*» j :- pop(U i :» popO t 

F I < J THEN pushU) ELSE push(0) END I 

*UXEQ*) j {■ popC ) j t :- pop(); 

F I <■ j THEN push(l) ELSE push(B) END I 

*UGTR*> j :- popUt i :- popO * 

P i > j THEN push(U ELSE push(fl) END r 

*UCEQ*) j t-"pop()| i x- pop()| 

P i >- j THEN pushd) BLSE push(ff) END I 

*TRA coroutine transfer*) 
Transfer (BOOLEAN{next(H # popO # popO) I 

*RDS read string*) k :» popO i i i- next(); 
REPEAT 

stk[k] t» next2(J) INC(k)jf DEC(l) 

UNTIL i < | 

•LODFW reload stack after function return*) 
:* pop{)f restoreExpStackj push(I) | 

•LODPD reload stack after function return*) 
t» pop{); j :- pop()f restoreExpStackj 
push(j); push(l) | 

♦STORE*) saveExpStack | 

*STOPV store stack with fonaal procedure on top*) 
:« popO? saveExpStackj stk[S] :■ lj XNC(S) | 

*STOT copy from stack to procedure stack*) 
itkfS] i- pop(); INC(S) j 

*COPT copy element on top of expression stack*) 
i* popOj push(i); push(l) I 
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266B; 
2676; 



(•DECS decreaent stackpolnter*) DEC(S) | 

(*PCOP allocation and copy at value parameter *) 

stk{LtnexM)l :• S; 

adr :■ popOi 



270B: 
27»B: 
272B: 
273Bi 
274ft; 
275B» 



sz ;- pop() ; k :* S+sz 
WHILE sz>0 DO 

stk{S) i" stkfadr) 
END | 

(*UADD*) j :« pop|)j 

(*USUB*J J t- popUl 

(*UHULM j :- pop(>; 

(*UDIV*) j t- pop(U 

(*UHOD*) J :- pop(t; 

(*ROR*) j :- popO, 
(* k j» J rightrotsted 



(*SRLM j t - popUl 
I* k t« J left shifted 



276BI 

277B: (*SHH*| j i- popOf 



INC(S)i INC(adr)j DEC(sx) 

■ pop!)* push(l+J) | 

- popOl push{l-J) I 

- popOl push(l*j) I 

- popOf push(l DIV j) } 

> pop(), push (I HOP j) | 

;■ popO HOD 16| 
by i places *) push(k) I 

;- pop!) HOD 16] 
by 1 places *) pusftlM I 

«• popU HOD 16, 



I* k ;- j right shifted by 1 places*) push(k) | 

300B: l*FORl enter FOR statement *\ 

1 :• nextOr (* -i; up; >g; down *| 
hi t* popOf low :- popO i adr t" popdi 
k s« PC + next2(); 
IP ((i - 0) AND (low <- hi)) OR 
1(1 I «) AND (low >- hi)) THEN 

stkfadr] j- low; 

stk(S) :« adrj iHCtS), StkfSJ :- hi* IHC(S) 
ELSE {* don't execute the FOR loop *> 

PC :■ k 
END | 

301B: l*F0R2 exit FOR statement *) 

hi :■ stk(S-lJi adr :- stk(S-2| f 

sz t* INT£G£ft(next() ) ; {* step range -128, . + 127 *) 

k ;» pc + next2(), 1 t- stk{adrjtszi 

IF ((sz >- •) AND (I > hi)) 

OR ((sz <« 0) AND (1 < hi)) 
THEN (» terminate *) DE€(S,2) 
ELSE (* continue *) stk(adrl :- 1} PC :» k 
END | 

302B: (*ENTC enter CASE statement*) 
PC :* PC ♦ next20i k ;* popO $ 
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low :■ next2(); hi ;» next2(); 

stk(S) :» PC + 2*(hi-low) + 4; INC(S); 

ir (It >■ low) AND (k <* hi) THEN 

PC :- PC + 2*(k-lowl1> 
END; 
PC j- PC * next2() I 

303B: (*£XC exit CASE statement*) DEC(S)f PC :- stk[S| I 

3MB; {*TRAP*) I :- pop{» i Trap(i) I 

3B5B: |*CHK*J k t« pop(); j t- popO ; * i- popO; push£i)j 
IP (INTEGER(i) < INTEGER (})) OR 

(INTEGER(i) > INTEGER(M) THBNTrap<4) END ) 

306B: (*CHK2*) 

k i- popl)* * «■ pop()f push(i); 
IF i>k THEN Trap<4) END I 

3078: (*CHK5 check sign bit*) 
k t» popOj push<k)j 
IF INTEGER(k) < THEN Trap(4) END I 

310B: (*BQL*| ) :- pop()| i i» pop()j 

IF i « j THEN push(1) ELSE push (3) END | 

31 iBt (*NEO*) J I* Pop()| i *» popOj 

IF i I j THEN pushM) ELSE push{0) END I 

312B: (*LSS*J j :- pop<) ; i :* pop()l 
IF INTEGER (U < INTEGER<j) THEN 

push(l) ELSE push (U) 
END | 

313B: (*LEQ*> j j- pop() * i :- pop<) * 
IF INTEGER! O <» INTEGER(j) THEN 

pushfj) ELSE push{0) 
END | 

3MB: <*GTR*> j t- pop( ) j i :» popO J 
IF INTEGERfi) > INTEGER(j) THEN 

push(l) ELSE push{0) 
END | 

31SB: <*GEQ*) j :~ pop() j 1 r- popO ; 
IF INTEGER (I) >» INTEGER(j| THEN 

push(l) ELSE push{0) 
END | 

3168: J*ABS*) pushfABS f INT£GER(popO ) ) ) t 
31 7B; <*NEG*| push( -INTEGER (pop< )) ) | 



iv. 
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32IB: 

322B; 

323B: 
324Bi 



325Bs 
326Bj 
3278: 
33BBt 

331B: 

1328j 

333Bj 

334B: 

335B: 
336ft: 
337B: 



♦OB*) j i* pop(|| I t- pop()j 

push [CARDINAL (B[TSET( I) ♦BITSETOm j 

*XOR*) J :- popCli I :- popOl 

pu8h(CAflDINAL(BITSET(l)/BITSET(j)»J | 

*AND*) j *- pop{); 1 s- popOl 

push(CARDIHAL(BITSET( I) *BITSET()> ) ) | 

•COM*) push(CAHDINAL([i . . 1S)/BITSET(pop() ) U t 

• IN*) j |- poptd i :« popO, 
IF i > 15 THEN push(ff) 

ELSIF i IN BITSET(j) THEN puahfl) 

ELSE push(S) 
END | 

•LIN load iMediate NIL*) pushtl 77777B) | 

*HSKM j ;- papO MOD 16; push(CARDINAL({S. .k-Hl 1 I 

•MOT*) 1 *» pOpt)} push(CAROSNAL(|lS)/(i))) | 



*ADO*) 
*SUB*) 
*HUL*) 
*DIV*) 
•MOD*) 



j i- popOf t *- popOl 
push(CARDlNAL(INTEGER(l) + IHTEG£R(j))) | 

j *» popOl i *-■ popU* 
pU8h(CARDIMAL(INTEGER(l> - INTEGER!)))) | 

j i- pop(), l :- popOi 
pushtCARDINAL{lNTEGER(l) * INTEGERf)))) | 

j i» POpOi i :- popOl 

pU8h|CARD!NAL( INTEGER^) DIV INTEGER (j) J) | 

J f pop(); t j« popOl 
puah{CARDlNAL<INTEGER(i> MOD INTEGER!}))) | 

*BIT*) j :• pop I) MOD I6i |* k ;- (J) *) push(k) | 

*NOP*) | 

•MOVF »ov« ftama *) i s- popOi 
3 t- pop()*popl)*4; (*I8 bits*) 
k ;» popO+pop()*4| (*|8 bits*) 
WHILE i>« DO 

stk[k| :- Stk|$)j IHC(k); iHC(j); DEC(t) 
END | 

348B: (*HOV «ova block*) 

k :* popUj J :- pop(); I :«• popUj 
NHILE k>g DO 

stk[i| ;- StkHIl INC(l)i INC{j)| DECfk) 
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END | 

34)6: (•CHP compare blocks*) 

k :• popOl 3 :* popl) $ i :* popU ; 

IP k»fl THEN pii5h(0); push(g) 

ELSE 

WHILE(stktl) | stk(jl) AND (k > U) DO 

INC(l); INC(j); DEC(k) 
END; 

push(stkf i]) i pushf stkl j] ) 
END | 

342B: |*DDT display dot*} 

k :» pop<); j x* pop Of dbmd :» popO? t i m popU 
(* display point at <j*k> in node i inside 
bitmap dbmd * J I 

343B; (*RE?L replicate pattern *) 

db :» pop()i sb :* pop(); dbmd :» popO ; i :* pop{) 
{* replicate pattern sb over block db inside 
bitmap dbmd in mode i *| I 

344B: (*BBLT bit block transfer*) 

sbmd :» popf) I <3I> :» pop{ ) ; sb :* popO j 

dbmd :« popOj i :* popO * 

(* transfer block sb in bitmap sbmd to block db 

inside bitmap dbmd In node 1 *) | 

* ■(« i. < * 

345Bj (*DCH display character*) 

j :* pop{); db ;■ pop{); fo :** pop(); dbmd :.» pop() 
(* copy bit pattern for character j from font fo 
to block db inside bitmap dbmd *) | 

346B: (*UNPK unpack*) k i= pop()? j t» pop{); i i» pop()j 
(♦extract bits i..j from k, then right adjust*) 
push(k) | 

' ' * ^ 

347Bs <*PACK pack*) 

k :« pop(); j := popUi i >■ pop()j adr :» popO t 
(•pack the rightmost j-i+l bits of k into positions 
i..j of word stk[adr) *) I 

358B: (*GB get base adr n levels down*) 
i :- tt j :« next() t 
REPEAT 

1 :* stklijj DECfj) 
UNTIL j-0; 
push(l) t 

351B: (*GBI get base adr 1 level down*) push<stk(L]) | 

352B: |*AIX0C allocate block*) 

t !• pop<)} push(S); S :■ S + t) 
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IP S > H THEM S :- pop()| Trep(3) CMD I 

35)8; (*EHTR enter procedure*) 
I ;» next|) j St- S+lj 
IF S > H THE** S t* S-lj TrapO) END | 

3MB: |*RTN return Crew procedure*) 

S :• L| L ;« stk{S+Mf i *<■ »tk{S+2J| 
IF I < W«i0§8 THEN PC :- 1 

ELSE G :- Btk[S]j F ;■ ltk{G)} PC >« I - I iitfiiB 
END | 

3558; (*CX call external procedure*) 
j t« nextOj 1 *■ nextOi 
»ark(G, TRUE) i G i- sutdtt+jll 
F i- stk(Glj PC :- 2*1* PC *- next2<) I 

3568: (*Cl call procedure at intermediate level*) 
I t" next Of aark(pop()« FALSE); 
FC :- 2*ij FC ;« next2() | 

3578: (*CF call foraal procedure*) 



1 

J 

F 



- stMS-U; *ark(G f TRUE); 

* I DIV 4»«B; G :- Btk|dft*Jlj 

» stk[GJi FC :- 2*|1 HOD 4898)} FC t- next2<) 



36B8; i*CL call local procedure*) 
i t- nextOi nark(L, FALSE) j 
FC i" 2*1 j FC ;« naxt2() I 

3618 .. 377B: (*CL1 - CL15 call local procedure*) 

■ark(L, FALSE) j FC :- 2*(1R HOD 16) ; PC ;- next2() 
END 
END (*LOOF*) 
END Interpreter. 



fc,\ 
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Appendix 2 

A benchmark test for Modula-2 implementations 

In order to provide a basis for measuring and comparing the 
efficiency of implementations of the language Modula-2, a 
benchmark program is proposed. It measures selectively various 
specific language features. Instead of relying on a built-in 
timing mechanism (which depends on »n underlying operating 
system and quite likely impedes the program's portability), the 
program merely counts the number of times certain statements are 
executed. Computation Is monitored and interrupted by the human 
operator equipped with a stop watch. Bach test Is selected by 
typing Its identifying character (a - o) j the end of the test is 
signalled by typing any character. Further details are to be 
derived from the program listing. 

The following figures have been measured for the Lilith, the 
POP- 1 1 /40 , and the Xe rox M to 2 computers . {On the Al to , the 
program was translated Into Hesa) . The timing period is 1 
minute for each test. Implementors of Modula-2 are encouraged to 
apply this test fully or partially to their system and to let us 
know the! r resul ts . 



facility 


Ll 1 1th 


POP- 11/40 


Alto 2 


a empty REPEAT loop 


321 


184 




b empty HHILE loop 


334 


185 


116 


c empty FOR loop 


422 


230 


172 


d CARDINAL arithmetic 


187 


84 


54 


e REAL arithmetic 


130 






f sin, exp, In, sqrt 


87 






g array access 


109 


54 


32 


h same with bounds tests 


89 


11 


26 


1 matrix access 


197 


93 


44 


j same with bounds tests 


164 


21 


36 


k call of empty procedure 


144 


37 


40 


1 with 4 parameters 


94 


29 


32 


m copying arrays 


63 


11 


56 


n access via pointers 


1 25 


66 


54 


o reading a disk stream 


287 




36 
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MODULE Benchmark; 
(*$T- 

a: empty REPEAT loop 

b: empty WHILE loop 

c: empty FOR loop 

d; CARDINAL arithmetic 

e: REAL arithmetic 

ft standard functions 

g: array of single dimension 

b; save as 9 but with index tests 

ii Matrix access 

j: sane as i but with index tests 

kj call of enpty, parameterless procedure 

1; call of empty procedure with 4 parameters 

m: copying arrays (block moves) 

m pointer chaining 

oi reading of file *) 

FROM Storage IMPORT ALLOCATE; 

FROM Terminal IMPORT Read , BusyRead, Write, WriteLn; 

FRQH InOut IMPORT HriteCard; 

PROM PileSystem IMPORT 

Pile, Lookup, ReadWord, Reset, Response} 
PROM MathLibi IMPORT sin, exp. In, sqrt; 

TVPE HodePtr - POINTER TO Node; 

Node - RECORD x,y: CARDINAL; next: NodePtr END ; 

VAR A,B,C: ARRAY ES..255} OP CARDINAL; 

M: ARRAY | § . . 99 1 , (* . . 991 OP CARDINAL; 
m: CARDINAL; head: NodePtr; 

PROCEDURE Test(ch: CHAR); 
VAR i,j,k; CARDINAL; 

r0, r), r2: REAL; pi NodePtr; 

PROCEDURE P; 

BEGIN 

END P; 

PROCEDURE Q(x,y«x,wt CARDINAL); 

BEGIN 

END 0; 

BEGIN 

CASE Ch OP 

"a": k ;« 200flij 
REPEAT 

k :- k-t 
UNTIL kii| 

"b": i ;- 2B#0f; 

WHILE i > • DO 
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END | 

"c*i POR 1 :« 1 TO 20800 DO 
END | 

*d": j j* 0; k :» 10000; 
REPEAT 

It ;« k-1; j :* j + 1; I t» (k*3) DIV (j*5) 
UNTIL k « | 

*e": k j» 5000; rl :* 7.28f r2 t* 34.8; 
REPEAT 

k t- k»l; r0 :» <rl*r2) / (rH-r2) 
UNTIL k - | 

"f": k := 500; 

REPEAT rl :- sin(0.7); rl :- exp|2.fl)l 

r0 :» ln(!0.0); rl J" sqrt(IB.B)f k :■ k-1 

UNTIL k - | 

■9"! k :« 20000; I := 8; B(0J :» 73; 
REPEAT 

A[i 1 :» 8[iJ; B|iJ :» A[i]; k i» kM 
UNTIL k » 8 I 

"h": (*$T+«) k :» 20000; I 1- 0; B[0] x- 73; 
REPEAT 

A[i| :- B(tll B f i] :» A[i]f k :- k-1 

UNTIL k»0 {*$T-*» I 

"i"i FOR I j= TO 99 DO 

rOR j (» TO 99 DO 

HU,J| *» N[J,i] 
END 
END I 

"j"! (*$T+*) 

FOR I 1- TO 99 DO 
FOR j :- TO 99 DO 

NtMl 1- MM) 
END 
END {*$T-*J I 

"k": k :- 28000; 
REPEAT 

Pj k :- k-1 
UNTIL k - I 

M"l k i» 20000; 

REPEAT 

Oli.),t,»)! k :» k-1 
UNTIL k « I 
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k :- 5tf9; 
REPEAT 

k :« k-l| h t' B| I !• C| C i" * 
UNTIL k « § t 



"n't It :» Sftff 

REPEAT p !• b«adj 

REPEAT p t- p".n«Xt UHTIL p - MIL} 

k s- k-1 
UNTIL k » » | 

"a"; k i- SBfgj 
REPEAT 

k :- k-1* Headword**,!) 
UHTIL k * If 
Rasat(f) 
END 
END T«St| 

VAR Ch,Chl; CHAR; 
m CARDINAL^ 

fi riUi 

qi NodaPtrj 

BEGIN Lookup(f ,-anyFilt-, FALSE); 
haad I" MIL* II !» liif 
REPEAT q :« ha ad; 

HEWfttead); ttaad'.next i- q; n t- n-l 
UNTIL n « ij 
WrUa(»>*># Raad(ctl|f 
WHILE ("*" <- chl * |ch < *p") DO 
Hrita(ch)j WrltaLnj a j- §; 
REPEAT H i» n*l| TasMchtl 

If (n HOD 5*) - i THEN MritaLtt END j 
Wrlt#(".»), BusyRaad(chl) 
UNTIL chl | §Ci 

Mr itiC*rd(n,6U HrtttLni Writ*{ N > a |i Raad(cti) 
END | 

Wrtta(MC) 
END BanCtwark. 



